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LIST OF SYMBOLS 

1 * FLOW CHART SYMBOLS 

Flow charts shown in this report conform to American National Standard 
X3. 5-1 970, "Flow Chart Symbols and Their Usage in Information Processing". 
Symbols of interest are defined below. 



Process: Computations storage move, etc. 



Input/Output 




Comment, annotation 


On-line storage (e.g., disk) 



Decision 



Predefined process, subroutine 
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Preparation, initialization 



Program terminus: begin, end, return, 
stop, etc. 

Flov/line connector - 

Parallel mode: multitasking, da tabus 


2. ACRONYMS 

The acronyms listed below are those of fairly general use within this 


report. 


APU 

Auxiliary Povjer Unit 

ATCS 

Active Thermal Control System 

CGI 

Computer-Generated Image 

C & W 

Caution & Warning 

ECLS 

Environmental Control /Life Support 

EOM 

Equations of Motion 

EPG 

Electrical Power Generation 

EPS 

Electrical Power Subsystem 

ET 

External Tank 

GN&C 

Guidance, Navigation & Control 

I MU 

Inertial Measurement Unit 

MDM 

Mul tipi exer/Demul ti pi exer 

ME 

Main Engine 

MPS 

Main Propulsion System 

MSBLS 

Microwave Scanning-Beam Landing System 

OMS 

Orbital Maneuvering System 


xvi 

rvsCDOniNEt.1. ASTeecrMAUTics 





MDC E1136 
2 September 1974 


PDR 

Preliminary Design Review 

PDRS 

Payload Deployment & Retrieval System 

PMS 

Performance Monitoring System 

PRSD 

Pov^er Reactants Supply & Distribution 

P/T 

Payload/Target 

RCS 

Reaction Control System 

SGLS 

j 

Space/Ground Link System 

SRB 

Solid Rocket Booster 

SRM 

Solid Rocket Motor 

SSFS 

Space Shuttle Functional Simulation 

STDM 

Spaceflight Tracking a Data Network. 

SVDS 

Space Vehicle Dynamic Simulation 

TAGAN 

Tactical Air Navigation 

TBS 

To Be Supplied 

TORS 

Tracking & Data Relay Satellite 

UHF 

Ultra-High Frequency 
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4.7.4 Power Generation Subsystems 

This section discusses the Electrical Power Generation and Auxiliary Power 
Generation. 

4. 7. 4.1 Electrical Power Generation 

The Electrical Power Generation (EPG) portion of the Electrical Power System 
includes three H 2 /O 2 fuel cells with associated water cooling loops; and the Power 
Reactant Storage and Distribution subsystem (PRSD). (The battery subsystem has 
been deleted.) The distribution and control of electrical power is accomplished 
by the Avionics Subsystem. 

EPG System Description 

Each of the three fuel cells contains subsystems which provide the following 
functions: 

e Heating and pressure regulation of the H 2 and O 2 . 
e Coolant circulation and control for proper temperature control. 

» Hg/Og circulation to remove product water from the fuel cell. 

Reference 25 provided Figure 4,7-65, a schematic of the fuel cell interfaces 
with'other systems. Figure 4.7-66 (also from Reference 25) illustrates the fuel 
cell internal operations and functions, which are discussed below. 

Fuel Cell 

The H 2 and Og fnom the PRSD are passed through pre-heaters (heat exchangers) 
which warm the gases prior to flow through coupled pressure regulators which 
maintain the proper operational gas pressures for purges and normal fuel power 
generation. 

The fuel cell coolant loop circulates a cooling fluid through the fuel cell. 
This fluid transfers heat from the fuel cell to the active Thermal Control System. 
The system includes coolant pump, flow control valve, condenser {heat exchanger), 
startup heaters, fuel cell coldplates, O 2 /H 2 pre-heaters (heat exchangers), and 
coolant accumulator. 

The Hg/Og circulation is accomplished by a combination pump/HgO separator. 

The flow is through the fuel cell, condenser, and the water separator. The fuel 
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cell product water is output to the ECLSS for storage and use. 

PRSD 

The Power Reactant Storage and Distribution (PRSD) subsystem comprises 
cryogenic storage tanks, control valves and distribution manifold. The Shuttle 
subsystem has two tank assemblies for O 2 and two tank assemblies for the H 2 * 
However, provisions of the manifolds allow the addition of cryogenic Og and Hg 
tank assemblies in the payload bay. Each tank assembly has two heaters, burst 
diaphragm and relief valve. The subsystem schematic from Reference 25 is shown 
in Figure 4,7-67. 

EPG Module Description and Performance Parameters 

The EPG module functions are to provide the calculations related to the fuel 
cell operations and the PRSD performance. Figure 4.7-68 is an illustration of the 
EPG module functional elements and their interfaces with other modules. The 
functions of each functional element are discussed in the following paragraphs. 

The module performance parameters for the fuel cell and PRSD are identified in 
Tables 4.7-19 and 4.7-20. 

Fuel Cell Pressure Control - The following calculations are provided by this 
element: 

■ « Electrode pressure - a function of temperature, gas quantity, gas 
volume. 

• Gas Usage rates - a function of electrical load, inlet pressure, electrode 
pressure, temperature, purge mode selection, and electrode differential 
pressures. 

® Electrode Gas Quantities - functions of regulator flow characteristics and 
gas usage rates. 

* HgO quantity - function of electrical load and electrode pressures. 

Fuel Cell Coolant Loop - This element makes the following calculations: 

» Pump flow rate - a function of loop configuration selection, fluid 
temperature, input voltage. 

« Pump outlet temperature - a function of inlet temperature, flow rate, input 
electrical power, and output hydraulic power. 
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TABLE 4,7-19 EPS FUEL CELL PARAMETERS (TYP 3) 


^ PARAMETER NOMENCLATURE 

DATA RANGE 

TYPE® 

LOW 

HIGH 

UNIT 

H2 Regulator Pressure 

0 

+100 

PSIA 

CP 

Voltage 

0 

+40 

VDC 

P 

Current 

0 

+500 

AMP DC 

P 

Cell Current Low 

LOW 


EVENT 

P 

Ready 

OFF 

ON 

EVENT 

I 

Start Up Heater 

OFF 

ON 

EVENT 

I 

Startup Heater - OFF 


ON 

EVENT 

I 

Stack Cool Out Temperature 

-50 • 

+300 

DEG F 

CP 

Condenser Exit Temperature 

0 

+250 

DEG F 

CP 

02 Flow 

0 

25 

LB/HR 

CP 

02 Regulator Pressure 

0 

+100 

PSIA 

CP 

H2 Flow 

0 

4.5 

LB/HR 

CP 

02 Purge Valve Automatic 


ON 

EVENT 

I 

H20 Condition 

ON 

OFF 

EVENT 

I 

120 Outlet Valve Position 

OPEN 

CLOSE 

EVENT 

I 

Product H20 Line Temperature 

0 

+200 

DEG F 

CP 

H20 Line Heater Active 


ON 

EVENT 

1 

H20 Line Heater ON 


ON 

EVENT 

I 

02 Pressure Over H20 

0 

+10 

PSID 

p 

H2 Purge Valve OPEN 


ON 

EVENT 

L 

H2 Purge Valve - Automatic 


ON 

EVENT 

I 

02 Purge Valve OPEN 


ON 

EVENT 

I 


^ P - Performance Parameter 
CP - Critical Performance Parameter 

I - Input 
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TABLE 4,7-20 EPS POWER REACTANT STORAGE AND DISTRIBUTION PARAMETERS 

(COMMON 3 FUEL CELLS) 


PARAMETER NOMENCLATURE 

H2 Circulation Isolation Valve lA OPEN 

HZ Circulation Isolation Valve IB OPEN 

H2 Circulation Pump lA ON 

H2 Circulation Pump lA Automatic 

H2 Circulation Pump IB ON 

H2 Circulation Pump IB Automatic 

H2 Circulation Line Heater No. lA-Active 

H2 Circulation Line Heater No. IB-Active 

H2 Manifold 1 Pressure 

H2 Manifold 1 Isolation Valve Closed 

H2 Manifold 2 Pressure 

H2 Manifold 2 Isolation Valve Closed 

H2 FCP 1 Supply Valve Closed 

iH2 FCP 2 Supply Valve Closed 

H2 FCP 3 Supply Valve Closed 

H2 Pressure 

H2 Quantity 

H2 Heater lA ON 

H2 Heater lA Temperature 

H2 Heater IB ON 

H2 Heater IB Temperature 

H2 Purge Vent Temperature 

H2 Relief Vent Heater 1 Active 

H2 Relief Vent Heater 2 Active 

H2 Relief Vent Heater 3 Active 

02 Pressure 

02 Quantity 



DATA RANGE 

TYPE^ 

LOW 

HIGH 

UNIT 


CLOSE 

OPEN 

EVENT 

P 


CLOSE 

OPEN 

EVENT 

P 



ON 

EVENT 

P 



ON 

EVENT 

P 

, 


ON 

EVENT 

P 



ON 

EVENT 

P 

- 


ON 

EVENT 

P 



ON 

EVENT 

P 


0 

+400 

PSIA 

CP 


OPEN 

CLOSE 

EVENT 

P 


0 

+400 

PSIA 

CP 


OPEN 

CLOSE 

EVENT 

p 


OPEN 

CLOSE 

EVENT 

p 


OPEN 

CLOSE 

EVENT 

p 


OPEN 

CLOSE 

EVENT 

p 


0 

+400 

PSIA 

CP 


0 

100 

PCNT 

p 


OFF 

ON 

EVENT 

p 


-425 

+200 

DEG F 

CP 


OFF 

ON 

EVENT 

p 


-425 

+200 

DEG F 

CP 


0 

+250 

DEG F 

CP 



ON 

EVENT 

p 



ON 

EVENT 

p 



ON 

EVENT 

p 


0 

+1500 

PSIA 

CP 


0 

100 

PCNT 

p 




. 

— 
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TABLE 4.7-20 (CONTINUED) 


PARAMETER NOMENCLATURE 

DATA RANGE 

TYPE^ I 

LOW 

HIGH 

UNIT 

02 Heater lA ON 

OFF 

ON 

EVENT 

P 

02 Heater lA Temperature 

-325 

+300 

DEG F 

CP 

02 Heater IB ON 

OFF 

ON 

EVENT 

P 

02 Heater IB Temperature 

-325 

+300 

DEG F 

CP 

02 Circulation Isolation Valve lA OPEN 

cLose 

OPEN 

EVENT 

P 

02 Circulation Isolation Valve IB OPEN 

CLOSE 

OPEN 

EVENT 

p 

02 Circulation Pump lA ON 


ON 

EVENT 

p 

02 Circulation Pump lA Automatic 


ON 

EVENT j 

p 

02 Circulation Pump IB ON 


ON 

EVENT 

p 1 

02 Circulation Pump IB Automatic 


ON 

EVENT 

P 

02 Circulation Line Heater No. lA-Active 


ON 

EVENT 

p 

02 Circulation Line Heater No. IB-Active 


ON 

EVENT 

p 

02 Manifold 1 Pressure 

0 

+1500 

PSIA 

CP 

02 Manifold 1 Isolation Valve Closed 

OPEN 

CLOSE 

EVENT 

p 

02 Manifold 2 Pressure 

0 

+1500 

PSIA 

CP 

02 Manifold 2 Isolation Valve Close 

OPEN 

CLOSE 

EVENT 

p 

FC 1 02 Supply Valve Closed 

OPEN 

CLOSE 

EVENT 

p 

FC 2 02 Supply Valve Closed 

OPEN 

CLOSE 

EVENT 

p 

FC 3 02 Supply Valve Closed 

OPEN 

CLOSE 

EVENT 

p 

H20 Relief Vent Temperature 

0 

+250 

DEG F 

CP 

FC H20 Relief Vent Heater 1 Active 


ON 

EVENT 

p 

FC H20 Relief Vent Heater 2 Active 


ON 

EVENT 

p 

02 Purge Vent Temperature 

0 

+250 

DEG F 

CP 

02 Relief Vent Heater 1 Active 


ON 

EVENT 

p 

02 Relief Vent Heater 2 Active 


ON 

EVENT 

p 

02 Relief Vent Heater 3 Active 


ON 

EVENT 

p 


^ P - Performance Parameter 
CP - Critical Performance Parameter 

I - Input 
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@ Coolant flow to ATCS - a function of condenser temperature, 

pump flow rate, startup heater inlet temperature, and condenser fluid ‘ 
outlet temperature. 

@ Fluid temperature to ATCS - a function of pump outlet temperature. 

9 Coolant flow to condenser - a function of coolant flow to ATCS, condenser 
H2O/H2 outlet temperature, startup heater inlet temperature, and condenser 
fluid outlet temperature. 

0 Condenser fluid inlet temperature - a function of condenser fluid flow 
rate, pump outlet temperature, condenser H2/H2O outlet temperature, ATCS 
fluid flow, and ATCS fluid return temperature. 

® Condenser fluid outlet temperature - a function of condenser fluid flow, 

H2/H2O flow, H2/H2O inlet temperature, and condenser fluid inlet temperature. 

e Startup heater inlet temperature - a function of stack inlet control valve 
characteristics, pump fluid outlet temperature, condenser fluid outlet 
temperature, condenser flow rate, and pump flow rate. 

9 Startup heater temperature - functions of heater electrical power, inlet 
fluid temperature, and fluid flov/ rate. 

0 Startup heater outlet temperature - a function of fluid flow, heater 
temperature, and inlet fluid temperature. 

0 Fuel cell outlet temperature - a function of the fuel cell temperature, 
pump flow rate, and startup heater outlet temperature. . 

a O2 Pre-heater fluid outlet temperature-- a function of inlet fluid 
temperature, inlet O2 temperature, O2 flow rate, pump flow rate. 

9 Og Pre-heater outlet O2 temperature - a function of inlet O2 temperature, 
inlet fluid temperature, and O2 and fluid flow rates. 

® Hg Pre-heater outlet fluid temperature - a function of Og pre-heater fluid 
outlet temperature, Hg inlet temperature, H2 flow rate, and fluid flow 
rate. 

9 Hg Pre-heater outlet H2 temperature - a function of O2 Pre-heater fluid 
outlet temperature, Hg inlet temperature, H2 flow rate, and fluid flow rate, 

® Fuel cell temperature - a function of electrical load, end plate heater 
power, O2/H2 flow rates, coolant flow rate, H2/H2O flow rate, coolant inlet 
temperature, and H2/H2O inlet temperature. 

H2/H2O Circulation - This element calculates the following: 

8 H2/H2O pump flow - a function of electrical input voltage, H2/H2O temperature, 
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rpnis and outputpower. 

4 

ES Separator HgO flow - a function of separator efficiency and H^O quantity 
Inlet. 

® Separator H 2 O pressure ~ a function of H^O tank pressure, and H 2 O flow. 

s Separator outlet H 2 O temperature - a function of inlet Hg/HpO temperature, 
input electrical power, and output hydraulic power. 

• H 2 pump outlet temperature - a function of the inlet H 2 /H 2 O temperature, 
input electrical power, and output hydraulic power. 

ft Hg pump outlet pressure - a function of H 2 temperature, and pump flow 
rate. 

e Condenser inlet Hg/HgO temperature - a function of inlet Hg temperature, 
inlet Hg flow, Hg/HgO pump flow, fuel cell outlet Hg/HgO temperature, and 
Hg/HgO pressure. 

Fuel Cell Electrical Output - This element generates the following: 

» Output voltage level - a function of reactant quantities at electrodes, 
output current, and fuel cell temperature. 

@ Output current - a function of load impedance, and fuel cell output 
voltage. 

PRSD - The calculations performed by this element are: 

® Reactant Quantities - functions of EClSS usage, fuel cell usage, and 
relief venting. 

® Tank temperatures - functions of input heater power, heat leakage, 
veactant flow rates, and pressures. 

a Tank pressures - functions of reactant quantities, temperatures, and 
vol umes . 

® Burst diaphragm rupture (discrete) - a function of diaphragm characteristics 
and pressure. 

@ Relief flow rate - a function of tank pressure, ambient pressure, reactant 
temperature, and relief valve characteristics {only after burst diaphragm 
rupture) . 

9 Manifold temperature - a function of inlet and outlet flow rates, and 
temperatures . 

® Manifold pressure - a function of inlet flow, outlet flow, and manifold 
temperature. 

reproducibility of the 
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« Manifold flow rates - functions of inlet pressure, inlet temperature, 
and outlet pressure. 

EPG Reference Data Sources and Data Formats 

Several sources of data exist for use for developing reference modules or 
making direct comparison with simulator results. The system and component design 
performance requirements, analysis/performance predictions, test results, and 
flight performance data are a few. Figure 4.7-69 is an overview flow chart of 
methods of using these sources in a direct comparison w.i^the results of. a. 
simulator run. In brief, the method is to establish the design requirement, 
analysis, etc. as input conditions on the simulation module to he verified. The 
simulation module is allowed to reach a stabilized response and the resulting data 
output for manual comparison with the spec requirements, analysis results, etc. 

This method is discussed in Section 4. 2. 1.4. The method of section 5.1 can be 
used with the reference models for verification. 

Fuel Cell 

The fuel cell requirements are provided by Reference 64 . The requirements, 
analysis and predictions can be determined from Reference 22, design or analysis 
groups, and MPAD. Many of the test results can be acquired from individual 
acceptance tests and integrated-systems checkout. Reference 63 discusses a 
computer program for simulation of the CSM fuel cells for the Skylab mission. 

The Shuttle fuel cell system is very similar to the one described by this 
reference; thus, the subject program should be easily converted for Shuttle 
simulation verification, 

PRSD - The basic flow for the PRSD O 2 reference module is shown in Figure 4.7-70 . 
This approach utilizes the basic flow charts shown in Figures 4.7-71 and 4,7-72 , 

The approach for PRSD-H 2 parameters would be Identical to the O 2 except for the 
fluid characteristics. Reference 65 can be used as a source of O 2 characteristics 
while Reference 66 provides the H 2 characteristics. Reference 22 ' provides many 
of the component characteristics of interest. 

EPG Validation Methods and Check Cases 

The reference module is utilized by the method of Section 5.1, while the 
systems performance data is used by the technique of Section 4.2 is validating the 
EPG simulation module. Drivers required to generate and maintain interfacing 
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FIGURE 4.7-70. PRSD REFERENCE MODULE OVERALL MATH FLOW 
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module Input parameters include: 

@ Atmosphere Revitalization 

9 Active Thermal Control 

e Avionics (Electrical Power distribution) 

9 H^O Management 
® Control Logic Inputs 

The check cases should include minimum, intermediate, and maximum electrical 
power load requirements, transient power switching loads, and projected mission 
load profiles. 

EPG Data Base I m ract 

The impact of the EPG validation on the simulator data base is in four forms. 
These forms are the reference module, required drivers, processing subroutines, 
and data files. The most significant impact is the reference module. The 
reference module includes the fuel cell and the power reactants systems. The 
drivers would have the next most significant impact. The drivers would be required 
for both the reference module method and the systems performance data method. 

The processing subroutines vjould include the data output routines {tables, 
plots, etc.) and any comparisons or data manipulations. The output routines would 
be required for the reference module and the systems performance data methods. 

Most processing routines would be common to all modules validated, hov/ever. 

Data files are required for the power load profiles, O 2 /H 2 cryogenic tables, 
and output data tables. 

4.7.4. 2 Auxiliary Power Generation (APG) 

The APG consists of three Auxiliary Power Units (APU's) which provide pov/er 
to the hydraulic pumps in the three hydraulic power systems. The three APU‘s 
are identical with each driving only one hydraulic system. APU’s are identical 
with each driving only one hydraulic system. 

APG System Description 

Figure 4.7-73 (taken from Reference 25 ) is a schematic of the APU used for 
the Shuttle Orbiter. The fuel (^ 2 *^ 4 ) expelled from the fuel tank by a fixed 

quantity of nitrogen used as a pressurant. A turbine-driven fuel pump feeds the 
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fuel through control valves into the gas generator. The gas generator is a 

♦ 

heated catalytic bed which causes decomposition of the fuel into a hot gas . The 
hot, high pressure gas is then used to drive the turbine and exhausted overboard. 

A gearbox provides torque and angular velocity transformation to drive the fuel 
pump, AC generator (if any), oil pump and hydraulic fluid pump. The oil pump 
circulates the gearbox lubricant through the gearbox and the water boiler for 
cooling. The lubricant in the gearbox is pressurized by a tank of via a 
pressure regulator. An electronic API! controller provides fuel flow modulation 
to allow startup, shutdown, and maintain normal turbine run speed, 

APG Module Description and Performance Parameters 

Figure 4.7-74 is a schematic showing the APG module functional elements and 
their interfaces with other modules. Table 4.7-21 is a listing of the APU para- 
meters. The functions performed by each element are discussed below: 

Fuel Source 

@ N 2 pressure - function of temperature. Helium quantity, and N 2 H^ 
quantity remaining. 

0 Tank (fuel) temperature - function of heater power, input, and 
usage. 

0 quantity - function of initial quantity and fuel usage rate. 

■ Fuel Pump 

# Pump flow rate - function of turbine speed and fuel density. 

9 Pump bypass rate - function of fuel delivered to the gas generator, 
pump flow rate, and control mode. 

a Fuel source flow rate - function of fuel delivered to the gas generator 
and control mode. 

* Fuel pump torque - function of friction, speed, flow, differential 

pressure, and moment of inertia. 


Gas Generator 

e Pressure - function of temperature, fuel inlet flow, gas flow out, and 
gas quantity. 

« Temperature - function of fuel decomposition rate, heater power, 
exhaust temperature, and turbine flow rate. 

a Gas quantity - function of turbine flow, fuel inlet rates, and 
decomposition rate, 
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TABU 4.7-21 .APU REFERENCE MODULE PARAMETER LIST (From Ref. 9 ) 

, *-4 


PARAMETER- NOMENCLATURE 

DATA RAN 

GE 

TYPE® 

LOW 

HIGH 

UNIT 

Shutdov/n Inhibit command 


ON 

EVENT 

P 

Propellant tank pressure 

0 

600 

PSIA 

CP 

Propellant tank temperature 

0 

+160 

DEG F 

P 

Tank heater-element A-B ON 


ON 

EVENT 

P 

Discharge Tine temperature 

0 

+160 

DEG F 

P 

Line heater-element A-B ON 


ON 

EVENT 

P 

Fuel pump di scharge temperature 

0 

250 

DEG F 

P 

Package heater-element A-B ON 


ON 

EVENT 

P 

Fuel Isolation valve-open command 


ON 

EVENT 

P 

Fuel Isolation valve position 

Open 

CLD 

EVENT 

CP 

Lube oil heater element A-B ON 


ON 

EVENT 

p 

Thermal bed heater A ON 


ON 

EVENT 

P 

Thermal bed heater B ON 


ON 

EVENT 

p 

Gas generator bed temperature 

0 

2500 

DEG F 

CP 

Controller power-on command 


ON 

EVENT 

p 

Status light - ready 

OFF 

ON 

EVENT 

p 

Start command 


ON 

EVENT 

p 

Turbine speed 

0 

lOOK 

RPM 

CP 

Gearbox Tube oil temperature 

0 

400 

DEG F 

CP 

Gearbox lube oil pressure 

0 

+100 

PSIA 

p 

Gearbox bearing temperature no. 1 

0 

500 

DEG F 

CP 


^ P - Performance Parameter 
CP - Critical Performance Parameter 
I - Input 
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Turbine 

0 Turbine speed - function of turbine torque, gear box lubricant 

temperature, hydraulic pump load, system friction, 
system moments of inertia, fuel pump rate, and AC 
generator output power. 

|A Turbine input power - function of turbine polytropic efficiency, gas 
inlet temperature, gas inlet pressure, and gas outlet 
pressure. 

s Discharge temperature - function of inlet temperature, turbine pov/er. 

« Turbine fuel flow - function of inlet pressure, temperature, outlet 
pressure, and effective turbine flow area. 


Gearbox 

Oil pump pressure - function of pump speed, oil temperature, and line 
resistance. 

« Oil pump flow rate - function of pump speed. 

® ,011 pump torque load - function of oil temperature, flow rate, and 
line resistance. 

9 Oil temperature - function of oil pump flow, return oil temperature, 
oil quantity. 

® Rate heat input - a function of friction and rotation (rpm). 

# 

APU Control 

e Valve control (s) - function of input commands, turbine speed, 
temperatures . 

APG Reference Data Sources and Data Formats 

The APG module can be verified by use of reference module{s) or system 
performance data. The reference module (s) should have incorporated the most 
accurate systems performance data in order to achieve a high degree of fidelity. 
The systems performance data would include design requirements, analysis results, 
test results, and vehicle flight data. 

Figure 4,7-75 is a flow chart utilizing the reference data sources for 
verification. The sources of the systems performance data include: 

e MC201-0001 (Reference 67 ) - provides system and component design perfor- 
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mance requirements. 

* 

e JSC-08934, Vol. I (Reference 22':) - provides a. compilation of design 

requirements, analysis results, test results, and performance 
predictions for various Shuttle systems. 

s SAPUCM (Reference 68 ) - the Simplified Auxiliary Power Unit Consumables 
Model allows the conduct of full consumable analysis for 
comparison with the simulation module, 

A reference module for the APU is shown in Figure 4.7-76 . 

APG Validation Methods and Check Cases 

The method of Section 5.1 and the selected reference module on the technique 
presented in Section 4. 2. 1.4 with the system performance data can be used for 
verification of the APG module. When utilizing the reference module, the following 
interface module drivers are required: 

« Hydraulic power - system functions, power load, and lubricating oil 
(Gearbox) coaling 

® Electrical power bus voltages 

® Control logic inputs 

Check cases should include startup, shutdown, steady-state maximum hydraulic 
load, steady state minimum hydraulic load, mission hydraulic load profiles, and 
hydraulic load switching. 

APG Data Base Impact 

The impacts on the simulator data base are associated with the reference 
module, special drivers and check case data files. The selected APG reference 
module v/ill have a large impact. The development of Figure 4.7-76 Into a 
reference module (or the use of some detailed model) will be the bulk of the impact. 

Special drivers v/111 also be required for the simulation module and reference 
modules. These drivers v/ould include the hydraulic pov/er subsystem, electrical 
power system, and control logic inputs. The hydraulic power subsystem driver would 
provide hydraulic pump loads and cooling for the gearbox lubricating oil. The 
electrical povvrer driver provides appropriate bus voltage levels for the heaters, 
control logic, and valve actuation. Switch positions, command inputs, and automatic 
inputs are provided by the control logic input driver. 
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FIGURE 4.7-76 . (CONTINUED) 
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LEGEND: " Gear Box mass 

^66 ^ Mass of Gas Generator 

^PA - Fuel mass available 

<fn^fRT Residual fuel mass 
^«*p- Fuel tank Ng mass 
-^erariz” Ng mass in Gear Box pressure bellows 

- Lubricant mass in Gear Box 

“ Gear Box - N^ source tank N 2 mass 

- Gas mass in Gas Generator 

^tuFi "* Mass of fuel in fuel line 1 (Run) 

Mass of fuel in fuel line 2 (Bypass) 

” Mass of fuel in fuel pump line 

- Mass of lubricant in oil base 
H - Mach number of turbine flov; 

Volume of N 2 in fuel tank 

- Fuel tank volume 

Gear Box Ng source tank volume 
Vo^iri~ Gear Box Ng bellows volume 
GasVyolume of Gas Generator 



~ Fuel tank and fuel temperature 
Fuel tank compartment temperature 
TpF-jrT Fuel pump inlet fuel temperature 
^p-o> outlet temperature 

Ti,-xT Gas Generator inlet fuel temperature 
Tpa-oT Lubricant pump outlet temperature 
~ Gear Box lubricant temperature 
%riittr~ Gear Box lubricant return temperature 
7£^- Lubricant temperature out of Hydraulic Boiler 
Gear Box N 2 source tank temperature 
Tes/^zr Gear Box N£ tank compartment temperature 
7^ “ Gas Generator temperature 
7i^c~ Gas Generator compartment temperature 
7^- Turbine outlet gas temperature 

«r- Fuel heat of formation 

FIGURE 4, 7»76. (CONTINUED) 
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f^ass flow rate of fuel from fuel tank 
•ApF“ Fuel pump mass flow rate 
wai- Fuel flow rate through startup line 
Bypass line fuel flow rate 
Lubricant pump mass flow rate 
Mg rate to Gear Box pressure bellows 
Gas flow rate through turbine 
ffp- Fuel density 

- Lubricant density 

- Time increment 

- Specific heat of fuel 

Specific heat at constant volume of N£ 

C, “ Specific heat of lubricant 

- Specific heat of Gear Box 

Cj-fr - Specific heat of fuel gases at constant volume 

- Specific heat of gas generator 

- Specific heat of fuel gases at constant pressure 
if^-Fuel gases specific heat ratio 

Ng gas constant 

- Fuel gas constant 

Fuel pump volume displacement per cycle 
V* Lubricant pump volume displacement per cycle 
fipf-' Fuel pump efficiency factor 
/Cp^- Lubricant pump efficiency factor 

- Fuel pump angular velocity 

- Hydraulic pump angular velocity 

“ Lubrication pump angular velocity 
Turbine angular velocity 

- Gear ratio of fuel pump to turbine 
M> “ Gear ratio of oil pump to turbine 

Gear ratio of hydraulic pump to turbine 

FIGURE rt.7-7P, (CONTINUED) 
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- Fuel tank pressure 

% - Gas generator pressure 
Fuel pump outlet pressure 
Afp— Fuel pump pressure rise 

Lubricant pump outlet pressure 
Afi - Lubricant pump pressure rise 

-* Gear Box lubricant pressure 
Gear Box Ng source tank pressure 
^ •* Turbine outlet pressure 

jjeater electrical pov/er 

- Gas Gefieratpj heater electrical power 

Ap,"- Fuel delivery line flow area 
Fuel bypass line flow area 
Asu'- Lubricant line flow area 
Af — Turbine flow area 

- Fuel pump fuel velocity 

" Fuel delivery line velocity 
Fuel bypass line velocity 
Lubricant line velocity 

^ep- Reynold's number for fuel delivery line 
Reynol d ' s number for fuel bypass line 
Reynold's number for oil Tine 
^/ “ Diameter of fuel delivery line 
Diameter of fuel bypass line 
ZJ, -* Diameter of oil line 

Roughness factor of fuel delivery line 
Roughness factor of fuel bypass line 
^p/“* Length of fuel delivery line 
Length of fuel bypass line 
4. - Length of oil line 

FIGURE /1.7-76. (CONTINUED) 
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^ - System friction at turbine , 

- on line friction factor 
•TfiLFi “ delivery line friction factor 
Jfnupz. - FiJ^l bypass line friction factor 

- Fuel friction due to line real ted to pump shaft 
/lap Fi^iction losses of oil pump 

Friction losses of fuel pump 
/tip Friction losses of hydraulic pump 
/o ~ on pump and line friction losses 
^ - Fuel pump and line friction losses 
Xpp - Fuel pump moment of inertia 

- on pump moment of inertia 

3^P — Hydraulic pump moment of inertia 
Jfn - Summation of pump and fuel inertias 

- Summation of pump and oil inertia 

- System moment of inertia at turbine 
Gear Box moment of inertia at turbine 
on pump hydraulic power load 

//pc" Fuel pump hydraulic power load 
//#<.— Hydraulic pump hydraulic power load 
Turbine power 

/4 “ Hydraulic power load for turbine 
~ Turbine efficiency 


FIGURE 4.7-76 . (CONTINUED) 
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The use of analysis/ test/design requirements reference data requires the use 
of special drivers. These drivers establish and maintain proper conditions in 'the 
module which correspond to the analysis/ test/ design requirements conditions. The 
plotting or outputting of the simulation data would also require special subroutines. 
However, the total impact of the analysis/test/design requirements is small. 

The use of input/output files for special check case profiles may be required. 
The profiles would include hydraulic power profiles for launch and reentry-through- 
landing. 
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4,7.5 Avionics 

Avionics subsystems are involved in sensing, communications, information 
handling, and control. The following subsections discuss avionics modules under 
the categories of Guidance, Navigation and Control; Communications and Tracking; 
Displays and Controls; Operational Instrumentation; and EPS Distribution and 
Control. Data Processing and Software functions are performed by flight hardware 
and software in the simulators of interest to this study. 

4.7. 5.1 Guidance, Navigation and Control 

Guidance, Navigation and Control subsystems and components are used for 
sensing vehicle-related observables, using these sensor data to estimate vehicle 
state variables, and defining and executing desired vehicle maneuvers. The 
subsystems and components in this category include inertial measurement units, 
strapdown gyros and accelerometers, propulsion systems interfaces, optical 
trackers, and the aeroflight control system. 
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ii.7.5.1.1 Inertial Measurement Unit (IMU) - The IMU is used to sense the inertial 
orientation and acceleration of the vehicle. 

IMU System Description 

Generally, three types of IMU's are employed in spacecraft: 

0 three-gimbal platform - as used in the Apollo Command Module. 

0 four-gimbal platform - as used in the Gemini spacecraft and currently 
baseliiicd for Shuttle (see Refs. 25, 69 ). 
e strap-down platform - similar to the backup attitude reference system 
on Apollo; considered as an alternate attitude reference system for 
Shuttle. 

Regardless of the type, the IMU outputs directly perceivable by the crew 
consist of three angular readouts v/hich describe the orientation of the spacecraft 
v/ith respect to an inertial reference. In addition, accelerometer outputs are 
input to the onboard computer for processing. In the case of the four-gimbal 
platform, the output of a redundant inner roll gimbal is also input to the 
onboard computer. This gimbal provides the capability of preserving the stable 
member attitude reference during "gimbal lock" conditions. The output of this 
gimbal is used by the flight computer to prevent gimbal lock, but is not 
normally displayed to the crev/. 

The performance verification methods presented in this section are 
particularly suited to the four-gimbal arrangement, since this design has 
al 1 -attitude capabilities under noniial conditions of body rates. Additional 
development would be requ- *ed to verify IMU simulation in and around the 
gimbal -lock regions characteristic of the other two types of IMU design. 

IMU Module Functions and Performance Parameters 

Figure A. 7-77 depicts the interfaces between the IMU module and the rest 
of the simulation. Inputs come from four basic sources: 

0 MDM (Multiplexer/Demultiplexer) , which provides the "operate" 
discrete and the flight software torquing and slew commands. 
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© EPS (Electrical Power System), which provides the 28 Vdc operating 
power. 

0 ECLS (Environment Control and Life Support) system, which provides 
the thermal control. 

0 Environment, which provides the vehicle dynamics sensed by the 
platform: angular rotation and inertial acceleration. 

Outputs of the IMU fall into four categories: 

e Status discretes which are used by the flight software and 
the Caution and Warning (C & W) system. 

e PMS (PerfovTnance Monitor System) Data, v/hich are used by the flight 

softv/are performance monitor system for its redundancy management function. 

0 Gimbal angle resolver data, which consists of sine and cosine data 
from the coarse (IX) and fine (8X) resolvers attached to the individual 
gimbals and is used by the flight software and the FDAI for determining 
the orientation of the vehicle with respect to the stable member of 
the platform. 

e Accelerometer Data, which consists of the AV accumulator outputs 
and is used by the flight software to determine the total inertial 
acceleration acting on the vehicle. 

Using the current Shuttle baselined four-gimbal platform as a reference, 
the performance parameters as defined in Ref. 25 are summarized in Table 4,7-22. 

Note on this table that the three primary gimbal angles (not the resolver 
sine and cosine outputs) have been chosen as critical performance parameters. 

The fourth gimbal is a redundant roll gimbal which is forced by the stabilization 
loop to remain at or near zero. It only has a non-zero value during the time 
that the platform is in the condition that would result in gimbal-lock in a 
three gimbal platform. Since the stabilization loop of the IMU is not expected 
to be part of the simulation software (Reference 32 ), the role of this redundant 
gimbal in the simulation is unknown. Some empirically-determined “kluge" 
simulation may be incorporated to provide a "wobble" in the FDAI during these 
conditions; hov/ever, verification of this implementation would be dependent on 
the manner of its simulation, and is therefore not addressed in this newsletter. 
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TABLE 4.7-?*2 . IMU MODULE PARAMETERS 


SYMBOL 

DESCRIPTION 

TYPE“ 


"Operate" discrete 

I 


Electrical power 

I 


Avionics Bay temperature 

I 


Gyro torquing and gimbal slew commands 

I 

LO 

Body angular rate vector 

I 

a 

-s 

Body sensed acceleration vector 

Status discretes (IMU ready* operate mode, 

I 


overtemperature, IMU fail) 

PMS data (redundant sensed angular rate, oven 

0 


temperature, IMU mode/EITE status 
Gimbal angle resolvers: 

0 


0 outer roll (coarse/fine) 

P 


© pitch (coarse/fine) 

P 


© yaw (coarse/fine) 

P 


6 inner roll (fine only) 

P 

(D 

Gimbal angles (roll, pitch, yaw) 

CP 

V , V , V 
x’ y’ z 

A V accumulator outputs 

p 

“imu 

Instantaneous accelerometer outputs 

CP 


LEGEND: 

I = input 

0 = output 

P = performance parameter 

CP = critical performance parameter 
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IMU Reference Data Sources and Data Formats 

Two methods are presented in this section to provide ideal (closed-form 
solution) IMU angular information in response to selected vehicle body rate 
inputs. The first method, the "constant rate input method", employs constant 
body rates or stable member drift rates as inputs, and computes the resultant 
gimbal angle time histories. The second method, the "closed-form gimbal angle 
input method", computes the body rate time history which must be input to produce 
a pre-selected gimbal angle time history. 

These methods apply only to the nominal operation of an IMU, Failure 
modes, effects of off-nominal temperature or power conditions, and control 
logic are not considered. In the design of these IMU reference math models, 
only rate and acceleration inputs and gimbal angle and accelerometer outputs 
are considered. Generation of status discretes and PMS data would require a 
high-fidelity representation of actual hardware operational logic, which is 
best obtained from test data. Similarly, determination of IMU responses to 
input voltages and temperatures will require test results from the actual flight 
hardv/are. Generation of the IMU responses to slew commands and gyro torquing 
commands would involve a high fidelity simulation of the flight hardware 
stabilization loop. Approximate data for the response to gyro torquing comjnands 
can be generated by equating the torquing commands to the gyro drift rates in the 
reference module presented in this section. 

Constant Rate Input Method - By holding the rate input to an IMU constant, the 
total angular displacement can be determined as a linear function of time. The 
corresponding IMU gimbal angles can be easily determined by first denning the 
total angular response in terms of quaternion elements. Once the time history of 
quaternion element variation 1s determined, the individual gimbal angles can be 
extracted from the body/lMU direction cosine matrix, v/hich is a function of the 
quaternion elements. 

Two types of rate inputs are considered: 
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0 body rates (p, q, r) - three components of angular velocity 
about the body axes» 

e drift rates (D , D , D ) - three components of angular velocity 

/\ j ^ 

about the stable member reference axes. (These rates can also be 
interpreted as gyro torquing commands from the flight software.) 

Both types may be input in a single run. Other Input data required are: the 

iteration rate (At) at which the resultant gimbal angles are to be printed 
outi the initial gimbal angles ( ); the body- axis referenced 

accelerations (A , A , A_), to check the IMU accelerometer computations; and the 

A j ^ 

time at which the run is to stop. 

Figure 4.7-78 presents a math flow of this technique. An initialization path 
is incorporated, to allow the capability to preset the gimbal angles to any value 
prior to initiating the input rates. Additional data Is computed (including an 
initial direction-cosine matrix, C) concerning the orientation of the angular 
velocity vector with respect to the initial stable member orientation, which 
serves as the inertial reference for the remainder of the computations. 

After the initialization pass, the gimbal angles at each time increment (At) 
are computed. This computation progresses as follov/s: 

1) Time is incremented by At. 

2) The total angular displacements of the body { ^ and of the stable 

member their initial orientations are computed as linear 

functions of time. 

3) The quaternion elements (d^ , d^, d^, d^) defining the angular displace- 

ment of the stable member arc computed as a function of total drift 
angle and the orientation of the drift vector. 

4) The direction cosine matrix (D) defining the orientation of the stable 

member with respect to its initial position is computed. 

5) The quaternion elements (r-j, r^, r^s r^) defining the angular displace- 

ment of the vehicle are computed as a function of the total displacement 
-^r, and the orientation of the rate vector. 
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FIGURE 4.7-73 CONSTANT RATE INPUT METHOD 
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6) The direction cosine matrix (R) defining the orientation of the vehicle 
with respect to Its initial position is computed from the quaternion 
elements. 

7) The direction cosine matrix (B) defining the orientation of the vehicle 
with respect to the stable member is computed as a function of the three 
previously defined matrices. 

8) The gimbal angles describing this orientation are extracted from the B 

matrix. The equations presented are valid for a gimbal sequence of 
yav/ ( 'I' ) , pitch {©), roll other sequences can be treated in a 

similar manner. 

9) The ideal IMU accelerometer outputs are computed using the B matrix 
and the input body-referenced accelerations. 

IG) The gimbal angles and accelerometer outputs are stored for comparison 
with simulation software outputs. 

Closed Form Gimbal Angle Input Method - The previous method is primarily suited 
to verifying the IMU performance during orbital conditions , v/here the body rates 
tend to be constant for considerable periods of time. It is also necessary to 
verify the IMU performance for variable body rates such as encountered during 
entry conditions. The math flow shov/n in Figure A. 7-79 describes a method for 
establishing a closed-form relationship between variable body rates and IMU gimbal 
angles. 

This reference module, given a desired IMU output time history, "inverts" 
the IMU transformation to generate the body-rate time history v/hich must be input 
to the IMU, To do this, it is necessary to restrict the form of the input. Each 
gimbal angle time -hi story must be an analytic function of time; thus the time 
derivative of the function (i.e., gimbal angle rate) is precisely computable. 

Three typical examples are: 

= A sin v/-jt ^ - k w-j cos w-jt 


© = ^ tan-'^ {^) 


e= 




^ = E [cos Wgt + (w^t) sin Wgt) ^ = E (w2t) cos Wgt 


With the gimbal angle rates thus defined, the corresponding body rates are 
determined by standard Euler transformations. The body rate data is then written 
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on an output tape for each computation interval required by the simulation 
software. 

IMU Data Base Impact 

Data base impact for initial IMU dynamical validation is very minor; only 
the above referep.. modules and a few mathematical subroutines are required. 
Revalidation of the basic IMU dynamics should be required rarely, if at all. 
Validation of subsidiary IMU outputs will require a certain amount of hardv;are 
test data, 

IMU Validation Methods and Check Cases 

Verification software structures employing the closed-form-solution reference 
modules previously described are shown in Figure a,7_bo . 

To use the constant rate input method, Figure 4 . 7 -DD (a), input constant 
body rates and/or drift rates to the IMU reference module and the IMU simulation 
module, thus obtaining comparable gim.bal-angle time histories. 

To use the closed-form gimfaal angle input technique. Figure 4,7-8n (b), 
select analytic functions of time to be used as inputs (see preceding examples). 
These time-histories and their derivatives are input to the reference module, 
v/hich generates body-rate tims-histories to be input to the IMU simulation module. 
The outputs of the IMU simulation module should then match the original gimbal- 
angle time histones. 

A set of check cases applying different combinations of magnitude and 
frequency inputs to the various IMU axes should be used for thorough validation 
of individual -axis responses and their interactions. Due to the analytical 
nature of the reference data, a highly-accurate match with simulation data 
should be demanded; e.g., one percent or better over time spans up to a hundred 
seconds. 
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4. 7, 5. 1.2 Strapdown Inertial Sensors ~ This section concerns those inertial 
sensors which are "strapped down"; i.e., rigidly mounted to the vehicle structure, 
rather than on a stable element. 

SIS System Description 

The SIS subsysterrv, as described in Refs. 25, 77 , consists of five identical 
sensor packages - three at various locations in the Orbiter, and one in each SRB. 
Each package contains a normal and lateral accelerometer, and orthogonal rate 
gyros to sense body roll, pitch and yaw rates. These sensors provide data for 
use in the vehicle attitude control loops. The SIS has also been considered for 
use as a backup navigation data source in the event of multiple IMU failures. 

This application vyould require the addition of longitudinal accelerometers . 

SIS Simulation Module Description and Performance Parameters 

The input/output interfaces of the SIS module are shown in Fig. 4,7-ril . 

Primary inputs are of course the body angular rates, the body-axis sensed 
accelerations of the center of mass, and the current c.g. position. The primary 
outputs are the simulated rate gyro and accelerometer outputs, which include the 
effects of sensor 1 '"cation, axis misalignment, and possibly hardware error 
characteristics . (Hardware error model ling may not be required, unless the SIS 
is used as a backup navigation reference.) Body bending and fuel slosh contri- 
butions to SIS outputs are discussed in Section 4.6 . Subsidiary inputs and 

outputs include electrical pov/er, avionics bay temperature, and various status 
and failure discretes. Table 4,7-23 provides a parameter list for the SIS 
simulation module. 

SIS Reference Data Sources end Data Formats 

Figure 4.7-R2 provides the math flow for a reference module which provides 
data for nominal SIS operation only. Off-nominal operation due to failures and 
voltage variations and temperature variations is not considered in this study. 

Two separate flow paths are shown on Figure 4.7-B2 : an error-free 
computation path, and a measurement-error path. On the error-free path, Equation 
(1) calculates sensed vehicle accelerations at the sensor-package location, in ideal 
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FIGURE , STRAPDOWN INERTIAL SENSOR HOOULE INTERFACES. 
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TABLE 4.7-23. STRAPDOWN INERTIAL SENSOR MODULE PARAMETERS 


SYMBOL 

DEFINITION 

TYPE^ 

x,y,7 

Body coordinates of center of gravity 

I 


Vehicle sensed acceleration 

I 

p,q>r; 

Vehicle angular rate and acceleration in 

I 


body axes 


AT 

Difference betv/een operating temperature and 

I 

*i ’■>'1 

calibration temperature of the SIS 
Typical sensor locations (in body coordinates) 

DB 


Accel erometer/rate gyro misalignments = 



misalignment in X-Y plane, ©= misalignment 
in X-Z plane, 9^ = misalignment in Y-Z plane) 

OB 

D 

Accelerometer dead zone 

DB 

£ j £ a^ 

Accelerometer measurement errors 

DB 

^Pd- 

Rate gyro measurement errors (roll, pitch, 


yaw drift rates respectively) 

DB 

a,- a 

Accelerations at the accelerometer, in 


— la 

ideal axes 

P 

^a 

Accelerations at the accelerometer, in 


misaligned axes 

CP 

Ptna^'^ma’^ma 

Vehicle angular rates, in misaligned axes 

CP 

1 


^LEGEND: 


DB = data base input 
I = input 

P = performance parameter 
CP = critical performance parameter 


A 
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sensor axes. Equations (2) and (3) then transform the ideal-axis accelerations 
and angular rates into true sensor-axis outputs, using small-angle relationships 
for axis misalignments. A single misalignment transformation is used for both 
accelerometer and gyro outputs, since the use of a typical misalignment provides 
all the generality required for a complete verification. 

The measurement-error computations are provided on the assumption that some 
or all of the simulations of interest will require sensor error modelling. Ihe 
measurement-error path is taken only when an input flag is set.' 


The accelerometer measurement error reference data is generated using Equations 
(4) and (5) of Fig. A. 7-02 , where D is from the data base and represents a typical 
dead zone or threshold below v;hich no acceleration is sensed, and the functions 
£: AY and sAl are generalized representations of the measurement errors that would 
be added to the true axis accelerations. Equation (7) presents an expansion for 
the accelerometer error function f A of Equation (5), using a standard modelling 
algorithm for typical accelerometer measurement errors. 




+ C^A, 


■f CjA,' 


+ C,2*2 + 4- 


(7) 


The parameters in Equation (7) are defined as follows: 


B = accelerometer total bias (mean + random) 

a 

A-|,A 2 ,A 2 = acceleration components along the input axis and the cross-axes, 
respectively 

= linear scale factor error 
= non-linearity error coefficient 
Cl 2 C.J 2 “ cross -axis sensitivity error coefficients 
AT = difference betv/een calibration temperature and operating 
temperature 

C-j^ = linear temperature error coefficient 
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It may not be necessary to model all the terms shown in Equation (7), 
depending upon the fidelity required. In addition. Equation (7) does not represent 
the most general case; for example, we could include higher order non-linearity 
terms, error terms proportional to acceleration products, and non-linear temper- 
ature variations. The necessary terms in the error model can be determined 
using vendor-supplied design and test data for individual errors, the real-v^orld 
sensor use, and the simulator's functional requirements. Typically, bias, linear 
scale factor, second order non-linearity and linear temperature error terms v/ould 
be all that is required for sensors ’ involved in a navigation function. 

Equation ( 6 ) provides rate gyro measurement error reference data, v/here the 
functions fPp, £Qp, and £Rp are generalized representations of measurement 
errors based on sensor design and test data. The error values output v;ould 
normally be added to the true rate outputs as drift rates. Equation ( 8 ) presents 
an expansion for gyro drift rate, using a standard modeling algorithm: 


£_ = + K.A. + K A + K A, + ... + K. A-A„ + A A 

D g 11 00 ss 10 10 os os 


+ K .A^A- -!• K. AT + 

SI S 1 t 


v/here the individual parameters are defined as follows: 


(8) 


A^ ,A^,Ag 




= gyro total bias drift (mean + random). 

- case accelerations along the input, output, and spin axes 
respectively. 

= anisoelastic drift coefficients .. 

= difference betv/een calibration temperature and operating 
tei:tperature 

“ linear temperature coefficient 


It may not be necessary to model all the terms of Equation ( 8 ), or it might be 
necessary to model additional terms; for example, drifts proportional to 
acceleration squared or possibly drift due to external magnetic fields. As with 
the accelerometer error modeling, gyro error model fidelity should be determined 
using vendor-supplied design and test data on individual errors, the real-world 
sensor use, and the simulator's functional requirements. 
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The gyro case accelerations shown as variables In the error functions of 
Equation (8) are the same as the body accelerations for the accelerometer error 
functions. The transformation of AX, AY, and AZ into gyro input, output, and 
spin axis accelerations depends on the individual gyro orientations. As a 
result the individual drift rate equations forEPj^, and will have 
different body acceleration components as the respective gyro axis accelerations. 
Since the error model is not affected by the preceding generalizations, there 
is no loss in the validity of the verificati'^'^ 

The data required for validation will nu.,nally be in hard-copy format. Basic 
information, such as sensor package locations and typical misalignments, should 
be found in Ref. 70 . Hardware error coefficients may have to be obtained 

from test reports or other less-accessible sources. 

SIS Validation Methods and Check Cases 

In general, checkpoint data will be required for both error-free and measure- 
ment-error modes of operation of the SIS module. Although reference-trajectory 
segments may be used to provide input data, selected discrete checkpoints will be 
simpler to implement, and actually give better results. 

For reference data not containing measurement errors, the inputs include 
sensor location in the body reference system, the center-of-mass accelerations, 
body angular rates and angular accelerations, and a zero value for the measurement- 
error flag. Only a relatively small number of independent input check points are 
required for a complete verification for this mode, since the equations involved 
are relatively simple. Sets of three widely-spaced 1 inearly-independent vectors 
in linear acceleration, angular rate, angular acceleration and axis misalignments 
v/ill provide a thorough validation exercise. Several sensor-package locations 
should be tested, including fore/aft, left/right, and up/dov/n displacements 
relative to the c.g. Agreement between reference and simulation data should be 
close to machine accuracy (e.g., five to six significant figures). 

When generating reference data for the error model verifications, the required 
inputs are the accelerations at the sensor in the sensor true axes (assumed the 
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same for both accelerometers and rate gyros), the operating temperature variation 
from that for calibration, and a positive value for the measurement-error flag. 
Data can be generated by varying the inputs selectively to magnify effects of 
different error terms. Comparisons can then be made which are identifiable with 
individual error components. Agreement should be within a few percent. 

When driving the simulator models to generate the corresponding data, we 
anticipate that some action will have to be taken to provide compatibility with 
the reference module execution mode. For example, contributions due to flexible 
body dynamics must be zeroed; simulation-module measurement-error models must be 
deactivated for non-measurement error check points. For the measurement error 
check points, sensor locations should be set to the center of gravity, with zeroed 
misalignments. Since the simulator software has not yet been developed, only the 
preceding generalizations are made with respect to interface initializations and 
input identifications required for the simulator module. 

SIS Validation Data Base Impact 

Data base impact for SIS module initial validation is very minor. The 
reference module is rather simple, and the use of discrete checkpoints obviates 
handling of large data files. Revalidation would only be required if significant 
changes were made in the measurement -error model. 
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4. 7. 5. 1,3 Propulsion Systems Interface U Us (PSIU's) - These units, which 
transfer data between the propulsion subsystems and flight computers and/or crew 
controls and displays, include the Main Engine Con troll er/Engine Interface Unit 
(MEC/EIU), the Solid Rocket Booster (SRB) interface, the Orbital Maneuvering 
System Thrust Vector Control {OMS TVC) interface, and the Reaction Control System 
(RCS) interface. 

Except for the MEC/EIU, these are rather simple hardware units, and we assume 
that their functional simulation, data-word generation/interpretation capabilities 
and malfunction-insertion provisions will be "embedded" in the module which 
simulates the corresponding propulsion subsystem. Only the MEC/EIU v/ill be 
described in any detail in this section; the other PSIU's perform the same 
general functions. 

PSIU Subsystem Descriptions 

The MEC hardware and functions are described by Ref, 62 , the MEC software 
by Ref 72 . The EIU is described by Ref. 73 , Specifications for the other 
PSIU's have apparently not been issued yet. 

The MEC and EIU together perform the following functions: 

G Accept discrete (e.g., start, shutdown) and variable {e.g., thrust level) 
commands from the Orbiter avionics. 

e Control SSME sequencing, thrust, and mixture ratio. 

D Perform engine checkout and monitoring. 

0 Transmit SSME checkout/monitoring data back to the Orbiter avionics 

G Perform self-test. 

Figure (after Ref. 62 ) shows the control and data Interfaces of the 

MEC/EIU, The EIU's role in control/data interchange is simply code conversion and 
formatting. Other PSIU's perform similar functions, except for thrust variation. 

PSIU Module Description and Performance Parameters 

PSIU simulation has wo aspects: functional simulation, and data-v^;ord 

generation/interpretation. From the functional viewpoint, we assume that each 
PSIU simulation is "embedded" in the module which simulates the associated 
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pfopulsion subsystem. Thus the overall command/ response characteristics of each 
propulsion module will be a composite of (a) the internal processing of the PSIU 
and {b) the response of the propulsion hardv/are - pumps, valves, combustion 
chamber and nozzle. Startup/shutdovm sequencing v/ill probably be simulated as 
empirical time functions for thrust buildup/tai loff . 

The other basic function of the PSIU modules is the handling of digital 
data-v/ords, including interpretation of command words received from the flight 
computers, and generation and formatting of monitoring and status words for 
transmission to the flight computers. These functions must be implemented pre- 
cisely to satisfy the flight software; however, they vn*1l be shared with or 
entirely absorbed by the Flight Hardware Interface Device (FHID), thus simplifying 
the simulation software. 

Each PSIU module will also require some failure-insertion provisions; 
simulated failures may affect either the functional simulation, the data-v/ord 
handling, or both. 

No performance-parameter tables are provided for PSIU simulation modules. 

Since PSIU simulation is embedded in the propulsion subsystem simulation module, 
the performance parameters for each such module will include both functional- 
simulation parameters and avionics-related command and status v/ords. For example, 
see Section 4.7. 3.1 for the SSME/HEC/EIU parameter table and simulation-module 
interface diagram. 

PSIU Reference Data Sources and Data Formats 

The functional performance of each PSIU simulation will be implicitly 
validated by end-to-end command/ response validation of the associated propulsion 
module. This will include static thrust levels, thrust buildup/tailoff , and 
{for the SSME only) throttle response. 

The basic source of functional -simulation reference data will be engineering 
simulations of each propulsion subsystem. Later in the program, engineering data 
will be refined using static-firing data; these data will be corrected for 
atmospheric pressure in the case of the larger engines, but vacuum-chamber firing 
data will be available for the smaller engines. These considerations are discussed 
in Section 4.7.3, 
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Conunand/status data-word formats must be verified bit-by-bit for each nominal 
and off-nominal case, the basic source of reference data being the most current 
version of each PSIU specification. 

Due to the complexity of the MEC/EIU, it may be necessary to verify this 
submodule in isolationj before integration with the basic SSME module. The 
hardware/software MEC simulation described by Ref. 74- tnay be a suitable source 
of reference data for such an exercise. 

PSIU Validation Methods and Check Cases 

Each composite PSIU/propulsion-subsystem module must be exercised over Its 
overall operating range, including startup, constant thrust, and tail off. 
Additional check cases will be necessary for the variable- thrust SSME. These 
will include static-thrust levels fv'om MPL to EPL, as well as dynamic throttle 
response to both increase and decrease commands over the operational static-thrust 
range. For simulators which use functional simulation of the flight software, 
the command inputs will be in the normal internal floating-point format of the 
host computer. 

For simulators using flight-computer hardware, inputs must be in the format 
in which they will be received from the flight compute r/FHID. The set of check 
cases must then be sufficient to verify that each PSIU module properly interprets 
all valid flight-computer command words, and returns the correct statos/monitoring 
words for all self-test modes, nominal and off-nominal operational modes. 

PSIU Validation Data Base Impact 

In the functional -simulation area, validation of the PSIU's contributes no 
data base impact, since PSIU functions are implicit in the end-to-end validation 
of the propulsion modules. 

Validation of digital data-word handling will require a command/response 
data-word "dictionary" covering the operational regime of the simulator of 
interest. For the MEC/EIU, this dictionary will be fairly extensive (several 
hundred entries); for other PSIU's, the dictionaries will be short (perhaps a 
few dozen entries). 
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4. 7. 5. 1.4 Star Tracker (ST) - Unlike previous manned space vehicles, the Orbiter 
provides fully automatic star/target tracking, v/ithout crew viev/ing of the tracker 
field. This section discusses the ST hardv/are and its flight-computer interface, 
as well as the functions and validation of the associated simulation module. 

ST Subsystem Description 

The ST is a strapdown, wide field-of-view (10 X 10°) image-dissector device. 

It provides automatic acquisition and tracking, under flight-computer control, of 
a selected star or sUn-illuminated rendezvous target. While tracking, it outputs 
the apparent magnitude and position in the field of the object being tracked. 

Its sensitivity (acquisition threshold) is variable on command; the maximum 
sensitivity is sufficient to acquire and track the 153 brightest starts (S-20 
magnitude), or a sunlit target whose apparent brightness is at least equivalent 
to an S-20 magnitude of +3 at a range of 300 nm. 

Despite the stray-light protection afforded by its light shade (LS), the ST 
may fail to acquire, or lose track on, stars or targets vihich are in the vicinity 
of other bright objects; e.g., the sun, moon, earth, or a brighter star. To protect 
the tracker from damage due to excessive input brightness, it is provided viith a 
shutter, activated by a separate bright source sensor. Field of view and response 
time of this subsystem are sufficient to prevent damage due to a bright object 
approaching at a rate of 10 deg/sec. 

The physical arrangement of the three ST/LS assemblies, mounted on the nav 
base for maximum accuracy, is shown in Figure 4.7-S4 (from Ref. 75 ); additional 
detail may be found in Ref. 76 , Note that #1 and #2 star trackers provide over- 
lapping coverage. 

Star tracker operational modes, internal signal processing, and command/data 
interfaces are indicated by Figure ^.7-S5. The modes of interest are: 
s Opan/close door 
e 5el f test 

0 Search/acquire star or target 
e Track star or target 
8 Break track 

0 Close shutter (bright source protection) 
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The star tracker door, in the left side of the Orbiter fuselage, is closed 
during ascent and entry, and opened on orbit. The self-test mode activates ST BITE, 
causing the ST to return a discrete indicating either operable or failed status. 

In initiating a search, the flight computer sets the acquisition threshold, 
and may also provide horizontal and vertical position offset coordinates. In the 
absence of offset coordinates, the ST searches its entire field, locking onto either 
the first catalog star acquired, or to the brightest object 1ii the field. If given 
an initial offset, it searches a reduced field centered on the offset point. In 
either case, a rectangular raster-scan search pattern is used, the search time 
will not exceed ten seconds, and the ST falls into the track mode. 

The ST rem-ins in the track mode until given a "break-track" command, the 
object passes out of the field of viev/, or it loses lock due to excessive vehicle 
rates or bright-source interference. Since the ST's are strapped-down, it may be 
necessary for Orbiter attitude maneuvers to be executed to maintain tracking. 

(Note that Ref. 75 does not presently define ST discretes for search failure or 
loss of target during track.) 

ST Module Description and Performance Parameters 

Star tracker functions will be simulated at varying levels of detail. Door 
opening and closing vnll be simulated as talkback, with time delay and allowance 
for malfunction insertion. Self-test operation can be simulated with a small 
command/ response dictionary which allows for nominal status and a repertoire of 
inserted malfunctions. 

To obtain realistic star selection and timing results, the search/acquire 
mode simulation will have to be rather detailed. For all stars which are not 
blocked by the sun, moon, or earth, and satisfy the magnitude criterion def ied 
by the current threshold selection setting, coordinate transformation and gating 
operations v/ill determine v/hsther they fall in the range of the scan pattern. To 
determine the first star acquired, a "lexicographic ordering" operation (see 
Ref. 77 ) will be required to determine which of the candidate stars is "nearest" 
to the starting corner (shown as the bottom-left corner in Figure ^.7-v56, in terms 
of scan-pattern coordinates. Hardware scan-rate parameters can then be used to 
compute the acquisition time. 
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FIGURE 4,7-36. TYPICAL SCA’I-PATTERfl RELATIONSHIPS 


t 


4.7-249 

/VscrooA/a'Ei-i. £50<L;GJL>fiis /^STftc^ti/Auireas crofiTFvarvv- ^r/isT 


MDC Ell 36 
27 January 1975 


The scan computations per se v/ill be simpler for target acquisition, or for 
the search mode in which the brightest object in the field is selected. However, 
computation of target brightness will require determination of terminator position, 
range to target, and target viewing aspect (e.g., broadside vs. end-on). 

Simulation of tracking outputs requires only a simple coordinate transformation, 
plus logic for loss of tracking due to excessive vehicle rates, movement of the 
object out of the field, and inserted malfunctions. Hardware error sources (bias 
and random) and stellar aberration due to Orbiter inertial velocity will also be 
simulated. 

Bright-source relative positions and closure rates must be simulated at all 
times that any star tracker Is operational. 

Star tracker simulation module parameters are listed in Table 4.7-24, and 
module interfaces are shown in Figure A.7.-87. 

ST Reference Data Sources and Data Formats 

Initial validation of the track mode is best supported using closed-form 
solutions, for several special orientations of the ST axes relative to the point 
targets used for testing. 

For more complete validation (all operational modes, interface with environ- 
ment and dynamics), a detailed reference module will be required. Two candidate 
reference modules have been identified. One of these v/as developed, checked out, 
and used for the study described in Ref, 78 . However, v^e recommend the module 
nov'/ being developed and checked out for inclusion in SVDS, the math flow of which 
(Ref. 79 ) is presented in Figure 4.7-88. Note that the search-mode simulation in 
this module only simulates the brightest-object selection criterion. Modifications 
will be necessary if the first-object-acquired criterion of Ref, 75 is actually 
implemented in the flight system. 

ST Data Base Impact 

The reference module for ST simulation validation is quite detailed; it will 
be of the same order of size as the ST simulation module for the SMS, larger than 
the one for the SPS. In addition, a driver routine will be required to generate 
Orbiter and target states and rates. Initially, these should be just synthetic 
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TABLE 4.7-24. STAR TRACKER MODULE PARAMETERS 


SYMBOL 

DESCRIPTION 

TYPE® 


Door-open discrete 

I 


Search-mode command discrete 

I 


Initial search position commands- (horizontal and vertical 
displacement) 

I 


Self-test mode command 

I 


Threshold-set command 

I 


Break-track command 

I 


Bus voltage 

I 

1 

Orbiter position & velocity (ECI axes) 

I 


Target relative position (Orbital axes) 

I 


Orbiter attitude 

I 


Orbiter angular rate vector 

I 


Star catalog (magnitudes , unit vectors in ECI) 

I 


Sun & moon positions (unit vectors in ECI) 

I 


Earth horizon altitude 

I 


Tracker alignment angles 

DB 


Horizontal £ vertical scan rates 

DB 


Tracker hardware errors (bias, scale factor, and random) 

DB 


Shutter-closed discrete 

CP 


Self-test data 

P 


Track-mode engaged discrete 

P 


Star/target tracking position (horizontal £ vertical 
displacement) 

CP 


Star/target apparent magnitude 

CP 


= input 

DB = data base input 
P = performance parameter 
CP = critical performance parameter 


• • / ^ u J I 
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FIGURE 'T.y-G? . STAR TRACKER SIMULATION MODULE INTERFACES 


HOC El 136 
27 January 1975 






“ /'l.'WS/iJi-i/OO aa>rJLflVf^O>£iJL^iV aVTS^rtOa l-t^NIVGSJOEAi 


Proijra" IT': 'in 

Purpose: Tc generate sliiulaled star irtcker neimrrnenl.s frojii velilcle trajectory 
and attitude liifarratlori. 


Inputs: 


nl3.3) 

annular rotatfons dff'niiig star tracker coordinate 
frar-.BS hHii l•rs[tact to the shuttle hody frame 

oa(3) 

angular fecto«' t: account for celestial body briniitness 

Rgt3) 

average radii of the uu>-tn, sun, and moon 

K-ATH 

amjuJar fae'or fir the anrtli's atnosphune 

Hr 

effective radius nf the narth for sun occultatlon 

H3ZV 

remlez.oiis trfcting flag 

FOV 

Star trjc'cr raatnr field a-* vietf (one half of the side 
of the square 1 

Arov 

auco-opLlcs field of view 

NSTAA 

niii'itur of stars In the star table 

crov 

half-angle of tl > clrculpr field of view enclosing 
tfie star tnatl'i’ *g.iirit raster field 

PJIAX 

ru«liiuia rariije f< r htacoii traekthij 

BIV.6 

beacon visual au'cnltinle 

1>!A5 

sun-111'. 1 -ulnd •jnei visual nagnltude 

T 

elapsed tir’d slice the c'ecii epoch 

A[J) 

vehicle ucsuloi. •jetior 

ftT(3) 

target vehicle poitllen vector 

ir<m 

star tratkiir nc'ijatlon *lajs 

KAUT0?(3) 

aulo-optics fla-ts 

he:o?i(3J 

teacofi tracking ! lags 

PSICf"1t2,3) 

auto-op' les angii’ ir corcsirdt 

TU(3.3) 

EC!-to-fici!y ira-isfoiit'atliin iiatrin 


lAllEin 
IHOtSE 
IIUSAL 
I SCALE 
IQUAVT 

CNDIS 

PH10.3) 

SF(3,E,3) 

OUWtT 


Qtil.puts: 

!TRAC(3) 

PS1(2,3) 

PS!0t!{2,3) 


error option flags 

constant for conputlng tracStor rolso standard diviation 
tracker inlsallneinent sectors 
tracker scale factor noni Inearltles 
deflection output quantitation level 


tracking flags 

Ideal star tracker defloctJon angles 
stn'ulated star tracker angles 



FIGURE 4.7-R8. STAR TRACKER REFERENCE MODULE MATH FLOW 
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FIGURE 4.7-8R 
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Stiliremttnei ftBERR (T, U, JST.ift) 


Piji*|iose: To eanpiite the shift In the apparent Itne of sight to a star iue t.) ■'otian 
of the Qvscrvlog vchtdo about chu sun. 

Imuts! 

T BlapicJ tlirm from the clock epoch 

(jJ3) geoiretrtcal Urte of sight to star 

Output; 

USTAhO) Hne-of-slght vector corrected for ahsrratfon 



(CONTINUED) 


MDC El 136 
27 January 1975 







SWSS>f30£2 ~3~^3n}rjf3C3C!*&V 



FIGURE 4. 7-fi8 


SiibrouUr? ELOC (V, Uh'. TIICTA, CrOlf, IDAY, tEAHTll, lOOCC) 

Purpttso: To lest F0\ iflterferctica by tfie eartli, sun, or irijon 

Srjiuts; 

M3) 

LV(3,3) 

1K£IA(3) 

crov 

rOAY 
tiiniH 


Identity of the otcuUing body 
IDOCC'I; eertli 
> Zx sun 
■■ 3: moon 


{CONTINUED} 



Output; 

toocc 


Mroet line of sight or 5T centerline 

unit vectors Froio the vebicle to the enrth, sun, or moon 

effective lial f-sntj1es of the earth, sun, and n«on sub- 
tended At the vehicle 

half-cone angle of the circular f leld-of-vlew entoppass- 
Ing the 5T search raster pattern 

orbital phase (d»y/rt1ghl) flag 

earth only flan 
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QU/WITIZE PSIO?: 

TEMP - W)OtPSIOJ(l). Qlim] 
PSIOB(l) • t’SlOJO) - TE«> 
TEMP • M0OCl‘SlO5(2). Q'JANT] 
P5109(2) • -'5108(2) - TEMP 



Subroutine 

Purpose: 'u sort out neuti 
view -incompess 

Inputs: 

STCEO) 

CFOV 

NSTAR 

0-Jtputs: 

STRDPT(10,4) 

NS 


-S. 
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ro 

I o 
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FIGURE 4. 7-H3. (CONTINUED) 


SCREEN (STCL, CFOV. NSTAR, STRBAT. NS) 

letlon stars which fall within the circular field of 
ng the ST search raster pattern 

ST centerline In ECl coordlnetes 

half-angle of the circular field of view encompassing 
the ST search raster pattern 

number of stars In the star ta'-'e 

star date {unit vectors and eugnltudes) of candidate 
stars 

number of candidate stars 
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lubrcutme StASCH (STCL, Crov, HSTAR, K£, HA'JTOP, 
»sicm, PSIMW, TSI, UU, IDAY, FOV. TSTR. ITRAC) 


Purpose: To detect s target star for tracking 


Inputs: 


STCL(3) 

star tracker centerline 

CFOV 

half-anglp of circular field of view enclosing the 
tracker search raster pattern 

HSTAR 

nuirber of start In the star table 

KE 

effective half-angle of the earth 

MAUTtf 

auto-optics mode flag 

PSUC«(2) 

auto-optics deflection conrands 

PSIKAX 

raster limit 

TSII3.3) 

ST-to-ECl transformation matrix 

IW(::,3) 

unit vectors from vehicle to the earth, sun, and noon 

lUAV 

orbital phase (day/nIght) flag 

FOV 

tracker search raster site 

Outputs: 

rSTIl'A) 

target star unit vector and magnitude 

iTRm: 

tracking flag 
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CALL SCRtEI (STC., CFO/, NSTAR 
snoAT, ns) 


I£ST VISIOIUTY OF JStT ::ATJ!DATE sur 

CALL VISIB (STftOAT(l.JS), KE. HAUfOP, 
-iCOH, P5IXAT, TSI, UV, IDAY, IDOCC) 


lOOCC • t; 


STORE VIS’Blt S^Ai UNIT 
VECTOR Af.3 Mr,r,v!T.OE; 

STATA'(T.JS) 
STH2A'12,.IS 
STR3A'(3,JS) 
S!PQA'(4,JS) 


VSTR{K,]) 
VSIR(F.,2 
VSTH(F.,3| 
VSTR(i;,4) 
IISTR • K 
K • A « 1 



StARCM-1 
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HA'JTOP\nO 


RETURN 


ITRAC - 1 
KAUTOP • Q 
PSIMAA • FOV 


SIIECT TARGET STAR FOR TRACKING: 
CALL SELECT (VSTB(T.4), MSTR, H) 


MAUI OP • 0 


RETURN 


(CONTINUED) 


SEARCH-2 


PRINT: ‘MO VISIBLE 
STAR IN AUTO-OPTICS 
RASTER AREA" 
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SubrouUne TRACK (TSTR, STCL CFll/. NSTAR, Kl!, f!AUT0», 
FS-’cai, RSIMAK, T5I, Ull, K\i, FOV, ITHAC) 


Purpose: To test tPe vijtblllty of the s'er -ting trerV.eil an<1 tu tearch for a 
new target ftar If the vtsibl 1(y teat Is fel'ed. 


^ START J 


Inputs: 

TSTR«) 

SICLO) 

crov 


riSTAR 

K£ 

KAUTOP 

PSICOt(Z) 

PSIHAX 

TSK3.3) 

UW(3.3) 

IBAT 

FOV 


Outputs: 

TST*(S) 

ITRAC 


target star uni', vector anil rvignttude 
star tracler ccnt:r11ne 


DFTE'IHINE THE VISIDIUTY OF 
STAR DEIH5 TRACKED; 

1 CALL VISIB (TSTR, KE. HA'JTCP 
PMC:h. PSIWX, TSI, UU, 
IDAT, I20CC) 


half-anglv of circular field )f view enclosing the 
tracker search 'astur patte'n 


number of stars In the sta*- tible 
effective h.»lf-anj1c of Ihs earth 
aulo-optfes aiode flag ‘ 

auto-optlcs defic:tlon co'runds 
raster Unit 

ST-to-EC! Iranjformatlon matrln 

unit vectors tron vehicle to the earth, sun, and noon 
orbital phase (daj'/ntght) flag 
tracker search rmer site 


target star unit vector and ragnttude 
tracking flag 
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Subroutlra VECELB {R, T. OEL. RO, Kn. RE, UW. THETA, KE, K.RE, IDAY) 

t 

Purposo: To compute ve!i1c)e-CO-ce1ettid1 bid> (tl'e eirth, sun, ard roon) unit 
vectors, hsK-an<j1cs of celostlil Indies, ind orbital pbaie. 

t 
1 

vehicle position vector ' 

elapsed tliw frwr the cleck eooch 

anjular factors t: account for celestial body brightness 
average radii of the earth, sun, and noon 
angular factor for the earth's atmosphere 
effective radios tf the earth for sun oecultallon 

f 

, I 

veh1cle-to-ce1est idt body unit vectors 

effective half-hfslcs of celestial bodies Including I 

glow 

effective lialf-anrles of the earth Including the 
at«v)sphere 

effective half-anrle of the earth for sun occultatlan 
day phase flag 


S 


In, huts: 

R(3) 

T 

OEU3) 

R3(3) 

KATM 

RE 

Outputs: 

UV(3.3) 

Tli£TA(3) 

rE 
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Ch 
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SubrijtlnB VISIB (V, KE. HA'JTOP, PSICtW, PS!I!A«, TSI, ItW. IDAt, ISOCC) 


Purfiose: Ts test the vUlbflity of e terget wUhln a spectfled raster area 

{searcs or auto-opt1cs). 
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tarn»t Mne of sight In tCI 

effective ha1f>anjle of the earth subtended at the 
vehicle 

auto-cptlcs iTude flag 
auto-optics angular comunds 
raster limit 

ST-to-ECl transforautlon ratrlh 

unit vectors from vehicle to the esrth. sun, and moon 
orbital phase (day/nlght) flag 


visibility flag 

I'JQCC • 0: target visible 

• 1: ear.th occuUatlon 

• d: target outside specified raster area 
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START 


TWISFOnn V TO ST C(0R3IWT£: 


CS";-'UTE ST DEFLECT !0» ANGLES: 

psun • /i’ftm [vsti:)/vst(3)] 

PSI(2) ■ ARCTAtl [VSTi;')/V5T(3)] 


PSICOMd) • 0 
PS1CCH(2) • 0 


tVUTOP 


DCLPSI(l) ■ |PSI(1) ■ PSICCMdt 
CELFSK?) ■ iFS!(2) • PS1C0H{?1I 


,/^lPSnij 's 
AND DELPSIC I 
S.< PS’ '•AX 


RETURN 
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states and rates; later, realistic vehicle dynamics can be provided by an EOM 
module. Hardware data (error sources and scan-rate parameters) and a star 
catalog complete the ST validation data base requirements. 
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4. 7. 5. 1.5 Aero-Flight Control System (PCS) - The FCS, which is used djring approach 
and landing, TAEM, and part of entry, is described in Ref. 30 , This 's a "fly by 
wire" system, with data handling and control functions performed by the flight soft- 
ware resident in redundant digital computers. The backup FCS is another digital 
computer (with identical CPU hardware and simplified software). 

Of the flight hardware involved in flight control, nost modules -- e.g., IMU, 
rate gyros, TACAil receivers -- arc covered in other sections of this report. The 
flight hardware modules v/hich vie have assigned exclusively to FCS are: 

» Aerosurface Actuator Interface Units 
e Air Data System 

4. 7, 5. 1.5.1 Aerosurface Actuator Interface Units (ASAIU's) - These are rather 
simple hardware units, with very limited simulation and validation requirements. 
Therefore, the discussion v/hich follows is rather brief. Additional information 
relating to somewhat similar hardware units (PSIU's) may be found in Section 

4. 7. 5. 1.3. 

ASAIU Description 

Like the PSIU's described in Section 4. 7. 5. 1.3, the ASAIU's provide interfacing 
between controlled hardware units (in this case, aerosurface actuators) and manual 
controls and flight computers, performing signal processing and checkout functions. 
When the control channels and aerosurface actuators are perfoming properly, the 
primary function of the ASAIU's is formatting and conversion of signals from and to 
the flight computers, to implement closed-loop vehicle control. 

The ASAIU's also implement "voting" of redundant conmands and feedback signals, 
enabling coiru-nand equalization as well as malfunction detection, isolation, switch- 
out and annunciation. Switchout of a malfunctioning actuator can be overridden by 
crew command, in the case of the quad-redundant hydraulic actuators used on the 
fast-response surfaces -- elevens and rudder/speedbrake -- these monitoring functions 
are implemented with rathe " complex and as yet ill-defined algorithms involving 
position feedbacks and hydraulic pressures sensed at multiple ports. For the dual- 
redundant hydraulic actuators used on the body flap, the implementation is similar, 
albeit simpler. 

4.7-271 

A7coo/v.v£:i.t aanGi-/'.s c:oAr/v»/v%' . r/isT- 


Mnc Ell 36 
27 January 1975 


Specifications and study reports defining command/response word formats, 
malfunction-handling algorithms, etc., have not yet been identified. 

ASAIU Module Description and Performance Parameters 

Again like the PSIU's, it seems reasonable to assume that the functions of 
the ASAIU's will be "embedded" in the associated actuator simulation modules. This 
is particularly true in view of the fact that the level of detail of actuator 
simulation will probably not be adequate to directly simulate the equalization and 
monitoring functions in high fidelity. That is, the actuators will be simulated 
basically as transfer functions with appropriate nonlinearities (see Section 
4. 7. 1.4); thus the physical quantities used in the monitoring process will simply 
not exist in the simulation. It may be possible to translate these physical 
parameters into their equivalent transfer-function variables. More likely, however, 
the simulation module v;ill simply talkback inserted malfunctions. 
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4. 7. 5. 1.5. 2 Air Data System (ADS) -- The air data system is used to sense the 
velocity and orientation of the Orbiter relative wind, providing data used for 
aeroflight control . 

ADS System Description 

Figure 4.7-fl9 shows an overview of the air data system and its hardware 
interfaces. The total system consists of: a set of dual -redundant probes, with 

associated deploy/ retract mechanisms and heaters; dual/dual-redundant air data 
transducer assemblies (ADTA) ; and electronics interfaces. The probes are deployed 
during the transition phase of entry, and air data outputs are used from then 
until landing. (See Refs. 25 , 82 .) 

Figure 4.7-90 is an expansion of an ADTA, identifying the individual 
transducers, calibration memories, and miscellaneous electronics. The ADTA has 
self-test and operate modes. Self-test data is evaluated by the GN&C computers 
to determine the status of each ADTA. In the operate mode, the ADTA responds to 
probe inputs to generate static pressure, total pressure, total temperature and 
differential pressure outputs. These are processed by the GN&C computer to 
compute airspeed, angles of attack, etc. 

ADS Simulation Module Description and Performance Parameters 

We assume that the ADS simulation module will provide a high-fidelity simu- 
lation of ADTA self-test and operate mode outputs and a time-delay 'simulation of 
probe deployment and retraction, will allow for various internal failure modes, 
and will respond properly to variations in simulated bus voltages. 

Figure 4.7-91 is an overview of ADS simulation module interfaces. Table 
4.7-25 provides an ADS module parameter list. 

AOS Reference Data Sources and Data Formats 

The ADS reference module discussed in this section provides a simulation of 
the nominal operation of the air data probes and the ADTA, and sets discretes for 
probe deploy/ retract and heaters without any detail simulation. The individual 
hardware elements of the air data system are not modelled in this reference module. 
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TABLE 4.7-25 AIR DATA SYSTEM MODULE PARAMETER LIST 


SYMBOL 

DEFINITION 

TYPE® 

- - 

Command for self- test mode or operation mode 

I 

Tc- Po 

Ambient air temperature and pressure 

I 

M 

Mach number 

I 


Angle-of-attack angle-of-sideslip and airspeed 

I 


ADTA self-test values for P^^-, P^^. , ,AP^. , and 

mode/status 

DB 

1 

Temperature sensor recovery factor 

DB 

Y 

Specific heat ratio for air 

DB 

^so’ ^to’ ^to 

Ideal probe values of static pressure, total 

P 

pressure and total temperature 


AP 

Ideal probe differential pressure (function of 

P 


vehicle aerodynamics) 



Changes in ideal probe values due to vehicle 

P 


dynami cs 


ePgi, eP^^., 
^^ti ’^^^i 

ADTA hardware errors 

P 


Indicated static pressure (-divided into most 

CP 

significant and least significant words) 


Pti 

Indicated total pressure 

CP 

1 ^ti 

Indicated total temperature 

CP 

AP, 

Indicated pressure differential 

CP 


ADTA Operational Mode and Status flag 

0 

- - 

Power-on discrete from ADTA 

0 

- - 

Probe heater status discrete 

0 

- - 

Probe deploy/ retract status discrete 

0 


^LEGEND: I = input 

DB = data base input 
0 = output 

P = performance parameter 
CP = critical performance parameter 
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Modelling of hardware errors is to be accomplished by means of "generalized 
functions" (table lookups, polynomials, etc.), based upon hardware test data. 

The math flow for module CKADS, as shown in Fig. 4,7-.38 , is initialized 
with constant parameters from the data base, and driven by checkpoint data 
provided either by an on-line driver routine or accessed from a predefined data 
file. It has two basic paths: one for the self-test mode, and one for the 

operate mode. 

Self-Test Mode - The ADS reference module simulates the ADTA self-test mode, 
normally initiated by the GN&C computer. Generation of reference verification 
data for the self-test mode is accomplished by simply setting the ADTA output 
to the values expected by the GN&C computer for a nominal status. 

Operate Mode - The operate mode simulates the functional situation in which 
dynamic sensor data is supplied to the GN&C computer for processing. Generation 
of the ADTA output during this mode is accomplished by exercising Equations 
(1) through (9) of Figure 4.7-92, discussed in the following paragraph. 


Equations (10),(11), and (12) provide the ideal values for total temperature 
(T^), static pressure (P^)* and total pressure (P^)» as measured by the air 
data probes. The equations presented are developed, using fundamental dynamics 
and thermodynamics of air, in Reference 81 


Tt - To(i o 


R 


P, 

P. 


= Po 

= Po (l.O + 

- fb (l-0 + 
/ 


7-1.0 , 

0 n ' 

'■'iev 

1.0+7 

2.0 


M*' 


PH-1 



1 

ffil-Ov-TlV 

'j47M^-2(7-1.0) 

H- 

for 1 

1 

for M51 


( 10 ) 
( 11 ) 
( 12 ) - 


Note that the probes are assumed to be located in the free stream ahead of any 
shock v/ave, and the temperature sensor is assumed to measure full adiabatic 
temperature increase within the recovery factor . 7 . Equations (10), (11), and 
(12) are for airflow axial along the probes, and will not provide the correct 
measurement when the incident flow is not axial. They are typical calibration 
equations; by additioi 'nj" correction terms dependent on vehicle parameters such 
as angle of attack, angle of sideslip, and airspeed, representative ideal values 
for Pg, P^, and T^ can be achieved for all vehicle states. The additive 

4.7-277 

MCOO/VtVBt-L. tSOUGLAS AST-ffGf^AtJ 3 JCS CGnSf*AIV\' m east 



CHECK POINT 
INPUTS 


RETURN 


4.7-273 

/iicnorvrvcL-L. oougl^s Asr-fto/v/iu-rtcs co/w»vi/w - uast 




• To 

• M 

• 

• vlhicle aero- 
dynamic 

VARIADLES 


' INITIALIZE > 
PWR, HTRS, D/RS 


P . •= SELF-TEST VALUE 


SELF-TEST VALUE 


T^. = SELF-TEST VALUE 


AP^ = SELF-TEST VALUE 


FiODE/STATUS = SELF-TEST VALUE 


MDC Ell 36 
27 January 1975 


• SELF-TEST VALUES 
« HARDWARE INFORNAT I0.‘ 
«Psi. ‘T^i 

«AP,-. ’ 

e AIRFLOW FUNCTIONS 


IDEAL CALCULATIONS 
P« = Po+fiP«(a.0.Vo.M) 

P« = Rj (l.O -I- + £Ro( . M) for 

p.= Po(.0<- for 

Tto = To (I■0^ ^2=^’JM’) + 

AR=ZiPo(c.^,'^M) 


for 

for M 5 ] 


riON-IDEAL CORRECTIONS 


P.. = P..+«P.^ 

5) 

Ri " fia 

6 ) 

\^X. + ‘Tf. 

7 ) 

ap=AP,+ *Ap 

8 ) 

MOOE/STATUS = HOMIWL OPERATION 

9 ) 


/ PERFORIWICE 
- -1 PARAMETER 
V OUTPUT 


c MOCE/STATUS 

• PWR 

• HTRS 

• 0/RS 


FIG'J3E 4 7-92 AIR DATA SYSTEfI REFERENCE DATA MODULE 







MDCE1136 
27 January 1975 

corrections indicated by 5 in Equations (1), (2), and (3) of Figure 4.7-92 
are derived from test data. 

The differential pressure parameter ( A P), is a function of vehicle dynamics 
and airflow around the probe, with the functional form heavily dependent on probe 
design and location on the vehicle. For the reference module, the ideal Ap 
is modeled using design and test data. (The flight software will contain an 
algorithm for converting Ap^- into sensed angles of attack; this algorithm will 
be essentially the inverse of the reference module algorithm.) 

The ideal inputs to the ADTA thus obtained are then degraded due to non-ideal 
operation of the hardware. Typically, hardware errors can be divided into tvio 
classes: those which are compensated for in the software accepting the data, 

and those not compensated for and thereby introduced into the system. Since the 
GN&C flight software will likely perform compensation for certain hardware 
characteristics, both types should be introduced to the ideal data. The reference 
module discussed here provides all hardware errors as additive terms (£) to the 
ideal values. The hardware error functions are determined using design and 
test data. 

The final output performance parameter, the mode/status flag, is assigned 
the appropriate value for nominal system operation. Since operate and self-test 
values may differ, the parameter appears in both paths of Figure 4,7-92. 

ADS Module Validation Methods and Check Cases 

ADS module validation is performed by driving both the simulation module and 
the reference module with corresponding input data. Check-case data required 
by the reference module are as follows: 

• Pov/er-off Data Check - The power off checkpoint is to verify that the 
power-off condition for the ADTA results in proper power-off output data. 
This single check point need not be built in to the reference module. 
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e Self-Test Data Check - The self-test check point is to verify the ADTA 
output in response to self- test commands. The reference output for 
this check point will consist of stored test words identical to those 
existing in the GN&C computer for verification of the ADTA status. The 
reference module input needs only the mode parameter to specify the 
self-test condition. 

0 Operate Data Check - This check consists of a series of check points 
chosen to verify the system output over its normal range of use. The 
reference data for this check is generated by a parametric variation of 
the inputs (P, T, , etc.) used in the calculation of the performance 

parameters. The appropriate parameter variations are selected based on 
performance specifications fc the air data system and the vehicle. 

The simulation module, being more directly hardware-oriented, will require 
additional input data (see Table 4.7-25) for proper operation. 

In addition to the discrete check points, the appropriate input values to the 
reference module may be stored along with resulting simulation module outputs 
from a simulation run. The verification executor can then access the data to 
drive the reference module and generate data for comparison with the stored 
simulation data. Hov/ever, care should be used in utilizing this option. Since 
the reference module does not simulate all the air data system hardware-related 
effects (e.g., malfunctions, voltage and temperature variations), the simulation 
data must be in the nominal operational regime to be directly comparable. 

For nominal operation, reference/simulation data agreement should be within 
a few percent for moderate mach numbers and angles of attack, during steady 
flight. Discrepancies of ten percent or greater would not be unreasonable at 
high mach numbers or high angles of attack, during turbulence or high g maneuvers. 


ADS Data Base Impact 

The parameters and functions indicated on Figure 4,7-92 as input through the 
data base must be available to the reference module from mass storage. Table 
4,7-2f^ presents the individual data base items, with an indication of the data 
source and added comments on the type of data. 
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TABLE 4.7-25 REFERENCE MODULE DATA BASE SOURCE LIST 


ITEM 

SOURCE 

COMMENT 

Self-test 

Values 

Air Data Subsystem 
Vendor 

Nominal Values indicating a "GO" status 

7 

Reference Simulation 
Standards 

Assigned Reference Value (e.g., 1.40 
for air) 

V 

Air Data Subsystem 
Vendor 

From Design or Test Data 

*Psi »«^ti 

eTti,*APi 

^Psi ’^^ti 

Air Data Subsystem 

Predicted static error data from design 

Vendor 

studies 

Vehicle Vendor 

From Wind Tunnel or Flight Test Data 


The complicated nature of the airflow functions and AP v/arrants the 

use of flight test data v/hcn available. Wind tunnel data or predicted values will 
in general provide only trend data, but should be used until flight test data 
becomes available. However initially obtained, the airflow functions should be 
updated upon the availability of flight test data to ensure a valid simulation. 

For all test data items, it is important that configuration control procedures 
be utilized to maintain up-to-date data base information. Reference module data 
base updates would result from system modifications and from the availability of 
more reliable data through program advances. When such updates are incorporated 
into the reference module, a reverification of the simulator air date module 
would be undertaken. If it is found that the simulator module is no longer valid 
with respect to the updated data, simulator management v/ould then be informed. 
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4. 7.5.2 Communications and Tracking (C&T) Subsystem 

The C&T subsystem provides capabilities for transmission l information and/or 
commands and determination of relative state variables betv/een ^he Orbiter and 
(a) ground-based facilities (see Section 4. 3. 2.1) and (b) payloads and rendezvous 
targets (see Section 4. 3. 2. 2). Orbi ter/payload communication and tracking is 
performed during the on-orbit mission phase; Orbi ter/ground communication and 
tracking may be performed during any mission phase - except for a short period of 
communications "blackout" during entry. 

C&T 'Subsystem Descriptio n 

The block diagram of Figure 4.7-93 (Ref. 70 ) provides an overview of the 
C&T subsystem. This subsystem includes several types of components: 

© receivers, transmitters and transponders 
© reccrd/playback equipment 

© data handling and distribution equipment (e.g., signal processors, coders, 
data interleavers, switching systems) 
e antennas 

e manual control and display interfaces 
e flight computer interfaces 

Component specifications (Refs. 83 through 92) provide detailed information 
relating to many of these components; specifications for other components have not 
yet been identified. 

C&T Module Description and Performance Parameters 

The C&T subsystem simulation module will consist of a number of submodules. 
Each such submodule will provide the operational modes and performance parameters 
of one of the basic hardware components of the C&T subsystem, model appropriate 
hardware errors, and allow for the insertion of simulated malfunctions. 

Table 4,7-27 gives a list of performance parameters for the C&T simulation module. 

Figure 4,7-94 shows the C&T module interfaces. Definition of the interface 
with the artificial environment module requires some assumptions about the soft- 
ware design. We have assumed that, for maximum module independence, each of these 
modules will require a minimum of information about the other. For example, the 
ground nav/comm module will compute the 1 ine-of-sight (LOS) to the Orbiter (as 
seen from the ground), in its own axis set, and use the ground-antenna gain pattern 
to compute its transmitted signal strength along that LOS. The onboard C&T 
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TABLE 4.7-27. COMMUNICATIONS AND TRACKING SIMULATION MODULE PARAMETERS 


SYMBOL 

DESCRIPTION 

TYPE® 

-SE 

Ground station coordinates (earth-fixed axes) 

I 


Ground station identification tags 

I 


Ground station transmitting frequencies 

I 


Line-of-sight contact flags 

I 

L* I 

Orbiter position and velocity (ECI axes) 

I 

Sr, 6v 

Target relative position and velocity (ECI or orbital axes) 

I 


Orbiter attitude 

I 

h 

Orbiter altitude (above local terrain) 

I 


Station range and range rate 

I 

^ZS’ ^S 

Station azimuth, elevation 

I 

Tf. f-r 

Target range and range rate 

I 

^ST’^TT 

Transmitted signal strength from ground station, target 

I 


Incoming and outgoing data/command streams 

I 


Onboard antenna gain patterns 

DB 

£t 

Line-of-sight to station, target (body axes) 

P 

^SR’^TR 

Received signal strength from station, target 

. .... 

h 

Transmitted signal strength to ground station or target 

P 

Dc 

Measured doppler counts 

CP 

^a 

Measured radar altitude 

CP 


Measured range to station, target 

CP 


Measured station-referenced azimuth, elevation 

CP 


Measured target angle and angular rate 

CP 


TYPE: I = input 

DB = data base input 

P = performance parameter 

CP = critical performance parameter 
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module will compute the LOS to the ground antenna (as seen from the 0rb1ter)i in 
its body-axis set, and then use the onboard antenna gain pattern and the transmitted 
signal strength to compute its received signal strength along that LOS. Thus, 
each module will need to know its own antenna patterns, but neither module will 
need to know the other^s antenna patterns. In addition, each module will need 
to output various flags and tags to inform the other which ground facilities 
are active and in viev/, which onboard subsystems are active, etc. 

The Shuttle Mission Simulator, which is sometimes used in integrated operations 
with Mission Control, must provide the capability to provide a simulated telemetry 
stream — realtime and/or recorder data-dump. This will require the C&T module to 
have telemetry simulation modes, in v/hich properly- formatted mass-storage files 
are generated during simulator opera tiona, then dumped over an appropriate cotnriuni- 
cation channel upon commands- received via the Mission Control communication link. 

C&T Reference Data Sources and Data Formats 

Figure 4.7-95 shows the math flow and variable definition for a module 
(CHKCMT) to generate reference data for validation of the C&T simulation module. 

The equations shown in this figure are derived in Ref. 93. Geometry calculations 
necessary to compute range, range rate, bearing, etc. are performed in terms of 
coordinate systems as shown in Figure 4.7-96; (see Ref. 47). In some cases, 
complete information required for equation development is not yet available, and 
computations are shown as generalized functions. These generalized functions 
may be implemented in computational form, or via table lookup, polynomial fit, 
etc., as the required data becomes available during the course of the Shuttle 
program. Status discretes and other secondary parameters are assumed set to 
their nominal operational values, and are not represented on the math flow. 

Note that this reference module is designed for initial validation of the C&T 
module, and includes computations which v/ill actually be performed by the artificial 
environment module. A simpler reference module v/111 be appropriate for integrated 
validation of the C&T and artificial environment modules. 

Command parameters (e.g., sv/itching, data-dump) normally generated by manual 
controls, flight computers, or ground command mus^ be provided by an external 
driver and/or manual data input to the reference module, in a format matching their 
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LE6EHD 


SYMBOL 

DEFINITION 

i 

Pass number 

<l>si 

Ground station latitude 


Ground station longitude 

hsi 

Ground station altitude 

N 

Number of Ground stations to be verified 

ae 

Earth semi major axis 

eg 

Earth eccentricity 

wt 

Angle between vernal equinox and Greenwich Meridian (Note 
t depends on time of reference frame initialization) 

w 

Earth rotation rate 

f1 

Function relating Doppler counts to range rate (Ground 
Transmission) 

f2 

Function relating antenna transmitted signal strength to 
line of sight (vehicle to ground station) 

f3 

Function relating antenna received signal strength to line 
of sight (ground station to vehicle) 

f4 

Function relating antenna transmitted signal strength 
to line of sight (vehicle to TDRS) 

f5 

Function relating antenna received signal strength to 
line of sight (TORS to vehicle) 


FIGURE 4. 7-nr, (COHCLUDED) . 
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Intended operational format In the eventual Integrated-simulator environment. A 
pseudo-data stream should also be provided to verify proper transfer of telemetry 
data. 


Note thatj to simplify the reference module logic, values for azimuth, 
elevation, range and range rate are computed for all ground station types, even 
though not needed In every case; e.g., elevation angle and range rate are not used 
for TACAN stations. 

C&T Validation Methods and Check Cases 

In accordance vnth the basic validation software structure described In 
Section 5.1, Figure 4,7-97 provides the math flow for a checkpoint-generation 
routine to be used in C&T module validation. This routine will provide, in 
addition to discretes for selection of operational modes, ground stations and 
TORS satellites, the following vehicle-dynamics-related data: 

X = (X,Y,Z,X,Y,Z) = shuttle state vector 

* « * 

X^ = {X^,Y^,Z^,X^,Y^ Z^) = rendezvous-target state vector 

B =3X3 coordinate transformation matrix 

T = universal time 

The logic of this driver routine provides for exercising the linkage between 
the Orbiter and every ground facility, as well as varying the relative position and 
velocity over the entire range of operational interest. For initial validation, 
synthetic state vectors will be used. Later, when a vehicle dynamics module becomes 
available, integrated validation will make use of realistic trajectories which 
pass into and through the regions of ground-station and payload contact. 

C&T Validation Data Base Impact 

The data base contributions for C&T module validation vn'll include the 
reference module, the checkpoint-generation routine, ground-station tables, 
antenna-pattern functions or tables, and temporary files of checkpoint inputs and 
outputs. 

The reference module and checkpoint-generation module are both fairly simple, 
and will impose little storage load. The ground-station table will may be fairly 
extensive {dozens or hundreds of stations, depending upon Shuttle operational 
rules), but will be comnon to the simulator data base rather than in addition to 
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it. The antenna-pattern data, if maintained in tabular rather than functional 
form, will also be extensive, but should also be common to the simulator. The 
extent of the checkpoint files will vary with the resolution desired for 
comparison plots, and in any event, these files need not be maintained after 
initial validation is completed. Overall, the data base impact for C&T module 
validation should be minor. 
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4. 7. 5. 3 Controls and Displays (C&D) 

The controls and displays group includes subsystems and components involved in 
the presentation of information to the flight crew and flight crew control of the 
Shuttle vehicle and its various onboard systems. It also includes the Master 
Events Controller (MEC), which transfers discrete commands from the flight computer 
to various pyrotechnic devices. 

Controls and displays will be discussed in four categories: timers (including 

the MEC), artificial feel system, miscellaneous display interfaces, and 
miscellaneous control interfaces. Flight-computer CRT/keyboard units are excluded 
from this discussion, on the assumption that they will be implemented using flight 
hardware on the simulators of intey'est. 

This discussion will be brief, since C&D software requirements are minor, and 
much of their validation will be done in an integrated rather than isolated-module 
configuration. 

C&D Subsystem Description 

Timers and MEC - This category includes the Master Timing Unit (MTU), the event 
timer, and the MEC. 

The MTU (Ref. 94), based on a crystal -controlled oscillator, provides 
(a) stable frequency outputs for use by various Orbiter subsystems and payloads, 
and (b) serial time code outputs for subsystems including computers, data 
acquisition systems, recorders, displays and attached payloads, it includes 
separate time accumulators for Greenwich Mean Time and Mission Elapsed Time, 
which can be set or updated by external control. 

The Event Timer (Ref. 95) is used by the crev; in execution of maneuvers and 
other onboard procedures. It accepts and counts timing pulses from the MTU (or a 
backup internal source), and generates a numeric display. Operational modes are 
count-up, count-down, reset, preset, and override. 

The MEC (Ref. 96) recognizes two types of discrete commands output by the 
flight computer: critical and non-critical . Critical command words must be 
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Miscellaneous Display Interfaces -• The display interface software will perform 
simple buffering, formatting and scaling of signals from the host computer. Some 
meters may require compensation-curve processing, based upon periodic calibration 
data. 


The caution and v/arning status display, if flight hardware, vnll interface 
directly with the flight computer. If Implemented as simulator hardware, it v/ill 
require flight-computer data conversion by means of software in the host and/or 

* V *■ 

the FEID. An interface with the aural simulation hardware will also-be required to 
generate tone, klaxon and siren outputs, used to indicate mission-critical anomalies. 

Miscellaneous Control Interfaces - The control interface software will simply 
buffer, format and scale discrete and continuous control inputs for the host and/or 
FC/FEID. 

Summary - Figure 4.7-98 depicts the C&D simulation module interfaces. Table 4.7-28 
lists the C&D simulation module parameters. 

C&D Reference Data Sources and Data Formats 

The basic sources of reference data are the specifications of the onboard 
systems, and of the simulator hardware and softviare for the particular simulator 
of interest. The simple C&D software modules Just perform a simulator-peculiar 
mapping of inputs to outputs -- e.g., discrete input frxxx is delayed for ttt 
seconds and becomes discrete output #yyy; so much controller motion maps into so 
many degrees of aerosurface deflection. 

C&D Validation Methods and Check Cases 

The bulk of the C&D validation is performed on the integrated simulator. 
Preliminary validation of discrete-data handling v/ould be done by means of an 
external driver and a command/response "dictionary." Preliminary validation of 
continuous-data handling would be performed by providing sampled inputs over the 
specified range {e.g., the input to a particular meter), generating a data plot 
to be compared to the meter calibration curve. 


NOT I 
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TABLE 4.7-2B. CONTROL AND DISPLAY MODULE PARAT'lETERS 


DESCRIPTION 

TYPE^ 

Hand-controller and rudder pedal deflections 

I 

Manual switch actions 

I 

Flight computer discretes 

I 

Flight computer continuous data 

I 

Avionics data: MSBLS, TACAN, IMU gimbals, etc. 

I 

Aerodynamic and runway velocities 

I 

Sensor and instrument scaling and calibration data 

DB 

Aerosurface deflection commands (manual) 

P 

Avionics mode and channel -select commands 

P 

Thrust commands (manual) 

P 

Displayed times: GMT, MET, event 

P 

Display discretes: C&W, channel set, etc. 

P 

Instrument drive signals 

P 

C&W panel settings; inhibits, limits, etc. 

P 

Discrete talkbacks 

P 


^TYPE - I = input 

DB = data base input 
P = performance parameter 
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C&D Validation Data Base Impact 

Very little on-line storage is required for validation of the C&D module, 
which requires no reference module as such. The on-line data base will consist of 
some short command/response dictionaries, a few calibration curves, and a simple - 
external driver module. 
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4. 7.5,4 Operational Instrumentation (01) 

The 01 subsystem provides the telemetry processing and Gaution and warning 
(C&VI) functions on the Shuttle Orbiter, The telemetry processing function 
consists of data buffering, scaling and fonnattlngj and control of onboard recording 
recorder dumping, and real-time teTemetry to the ground network. The cautTon and 
warning function consists of buffering, filtering and gating data, and generating 
display messages in response to detected anomalies. 

These functions are all implemented in flight software In the Orbiter flight 
computers, and will thus require no simulation software in the simulators of 
interest, which will incorporate flight computer hardware. In the SMS, which 
simulates most onboard subsystems in high fidelity, 01 implementation will require 
the subsystem simulations to provide realistic values for such performance- 
correlated variables as temperatures, voltages, and various operational discretes — 
over and above a correct representation of subsystem functions, in the SPS and 
OAS, we expect little or no implementation of 01 functions, and much-simplified 
representation of most onboard subsystems. 

The telemetry and maintenance recorders are discussed under C&T (Section 
4.7. S. 2), and the C&W displays under Controls and Displays (Section 4. 7. 5, 3), 
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4*7. 5. 5 ETsctncal Power Distribution and Control 

The Electrical Power Distribution and Control (EPD&C) subsystem provides the 
means of conditioning and transfer of electrical energy from the fuel cells or 
ground support equipment (GSE) umbilicals to tho various systems electrical 
equipment. In addition, the subsystem includes external vehicle i 11 umi nation. 

This section provides a discussion of the subsystem components, module performance 
parameters, reference data sources, validation methods, and impact to the 
simulation data base. 

EPD&C Subsystem Description 

Figure 4.7-99 is a schematic of the EPD&C subsystem. The means of energy 
transfer is a network of bus bars which are connected by electrical cables, power 
relays, solid state power controllers, fuses, etc. This network of buses includes: 

® 3 main buses 

© 3 essential (critical) control buses 
® 3 forward local buses 
® 3 midsection local buses 
© 3 aft section local buses 
0 3 AC 3-phase buses {powered by 3 inverters) 

The three main buses can be individually interconnected by a tie bar which also 
allows connection of the tie bar to GSE power via the nose-wheel umbilical. The 
three aft local buses can be individually connected to GSE power via the aft GSE 
power umbilical. The three aft local buses can also be connected together via a 
tie bar. The 3-phase AC buses can also be electrically connected by tie bars. 

The illumination system block diagram is presented in Figure 4.7-ino. The 
exterior lighting is controlled by manual switching. The lighting includes landing, 
navigational, anti-collision, rendezvous, docking, manipulator, payload and camera 
lights, 

EPD&C Module Description and Performance Parameters 

The Figure 4,7-101 schematic illustrates the EPD&C module interfaces with the 
other modules and shows the functional elements within the module. The performance 
parameters of the module are listed in Table 4,7-29. The module functional 
elements provide the following calculations: 
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TABLE 4.7-20, EPD&C PERFORMANCE PARAMETERS 


PARAMETER 

type® 

Switch position, selections, etc. 

I 

Equipment operating modes, on/off 

I 

FC electrical outputs - (Norton's equivalent current, admittance) 

I 

GSE electrical outputs - (Norton's equivalent current, admittance) 

I 

Equipment temperatures 

I 

Bus voltages 

CP 

Load voltages 

p 

Bus currents 

CP 

Load currents 

p 

Bus distribution admittances 

p 

Load admittances 

p 

External illumination light operating modes 

p 

Power interruption devices - total current 

p 

- overload trip time 

CP 

- device open 

* 

p 


®TYPE: 

CP = critical parameter 
P = performance parameter 
I = input 
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« Loads - determine the admittance values of each load as functions of 
operating mode, input voltage, and temperature. 

® Control logic - determines enabling/ disabling selection logic from the 
control inputs, 
d AC inverter - calculates: 

— Inverter AC load - determines inverter load-phase as functions 

of AC voltage, mode selected temperatures. 

— Inverter efficiency - this is a function of inverter temperature, 

AC load, and input DC voltage. 

— Equivalent DC load - a function of inverter efficiency and 

inverter AC load. 

a Distribution resistances - calculates the bus network distribution 

resistances as functions of the control logic, and bus voltages, 
e Distribution voltages and currents - calculates bus and load voltages and 
currents as functions of the fuel cell current/ admittance, load 
admittances, and distribution network resistances, 
i Power interruption - sums current through the power interv'uption devices, 
determines overload conditions, integrates overload time, and sets 
, logic indicating power line open. 

0 External illumination - determines light operating mode and on/off 
condition from control logic and bus voltages. 


EPD&C Reference Data Sources and Formats 

The component design performance requirements, performance predictions, test 
results, and flight vehicle performance results can be used as reference data 
for direct comparison with simulation results. Reference 22 is Specifically 
intended to provide data of this type. Component design requirements are defined 
in the following Rockwell International documents: 


COMPONENT 

Fuses 

Thermal circuit breakers 
Remote control circuit breakers 
Remote power controller 
AC inverters 


SPECIFICATION 

MC451-0010 

MC454-0026 

MC454-0027 

HC450-0017 

MC495-0012 
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Various analysis computer programs are available for use in providing reference 
data. One such program is the Shuttle Electric Power System Analysis Computer 
Program (SEPS) developed by TRW for the consumables analysis section of the Mission 
Planning and Analysis Division (see Ref. 100). The subroutines used In the SEPS 
can be easily developed into an adequate reference module. The complete develop- 
ment of a suitable module would be a Y'elatively simple and straightforward task. 
Figure 4.7-102 is a generalized overview of the module operations. 

Figure 4.7-103 provides an equivalent DC circuit for the Shuttle EPD&C. It 
also shows the defining matrices for the circuit assuming the switches are all 
closed and the diodes are forward-biased. The defining matrix equation is: 

[I] = [6] [E] 

where [I] = column matrix for the node input current sources 
[S] = square admittance matrix of the circuit 
[El = column matrix of the node voltages 

The node voltages can be determined from the following equation: 



* E„ = x-node voltage 

’ A 

= value of the determinant of [G] 

^ = value of the determinant of the matrix resulting by replacing 

A 

the X column of the [G] with [I] 

The analysis of the circuit with all switches open is similiar with the resulting 
matricej being less complex. 

EPDSC Validation Methods and Checkcases 

The methods of Sections 5.1 and 4.2 can be used in validating the EPD&C 
simulation module. A comparison of the parameters listed in Table 4.7-29 and 
bus power, load power, fuel cell input power, fuel cell input v/att hours, and 
ampere hours, should provide adequate checks. During the module runs, interface 
drivers will be required to provide the input parameters from the interfacing 
modules. It will also be necessary to provide drivers to initialize or hold 
static the Intermodule parameters and conditions. Drivers required are: 

• FC electrical outputs 
® Equipment operating mode, etc. 
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FIGURE 4.7-102 


ELECTRIC POWER DISTRIBUTION AND CONTROL SUBSYSTEM REFERENCE MODULE 
MATH FLOW. 
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LEGEND: 

Yasl = AC load admittance 

Vac = AC bus voltage 

= logic inputs 

= Sum of AC loads on AC inverter 
Sx - Inverter electrical efficiency 

®ACI " Equivalent DC load representing inverter and its AC loads 
= Individual DC load resistances 
= Line resistance from load to bus 
6j = Sum of bus load admittances 
02 = Bus interconnection admittance (DC) 

= Bus voltage 

Ay = Value of determinant of the admittance matrix v-iith x-column 
^ replaced by current matrix 

= Value of the determinant of the admittance matrix 

i = Current 

E = voltage 

P = Power (electrical) 

B = Interruption state of power interrupt devices (fuses, circuit 

, breakers, etc.) 

At - Time increment 

T = Temperature 


FIGURE 4.7-102 (CONTINUED) 
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LEGEND: 

^FCA 
^ FLB ^ 
^FLC ^ 
®FCA 
%CB > 
®FCC 
%C(>M 


= Norton's equivalent current sources representing the fuel cell 
A, B, C outputs. 


- Norton's equivalent admittance for the fuel cells As B* C. 
= Admittances connecting fuel cell output to main buses. 


G 




'A 


G 


^LB 

^TMA 

*"TMB 

®TMC 




LAA 

LAB 

"LAC 

"LA 


"AA 


"CA 


= Equivalent loads on main buses A, B, C including forward local/ 
middle local /AC bus loads and wiring losses. 


= Admittance between main buses and AFT local buses A, B, C. 


= Admittance loads on AFT local buses A, B, C. 


= Admittance between AFT local buses A, B, C and AFT Bus Tie. 


= Admittances between main buses A, B, C and main Bus Tie. 


= Admittance between main buses A, C and essential bus A, 


FIGURE 4.7-103. (CONTINUED) 
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Admittances between main buses A, B and essential bus B. 

Admittances between main buses A, B and essential bus C. 


Admittance loads on essential buses A, B, C, 


Fuel cell output voltages. 


Fuel cell A, Bj C input voltages. 


Main buses A, B, C voltages, 

Main bus tie-bar voltage. 

AFT local tie-bar voltage. 

Essential buses A, B, C voltages. 


AFT local buses A, B, C voltages. 

Value of the determinant of the G-matrix {[G]) 

Value of the determinant of the matrix resulting by replacing the 
x-column of the G-matrix with the I -matrix. 

Switch. 

FIGURE 4.7-103. (CONTINUED) 
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e Equipment temperature 

& Control logic (switch positions) 

® Prelaunch/launch interface - GSE electrical inputs parameters 

The check cases implemented should include step changes in loads, bus switching, 
maximum equipment powered, minimuni equipment powered, and expected mission load 
profiles (equipment powered time-line). System checkout or test sequence results 
can be input as check cases with simulation results compared directly to the test 
results, 

EPD&C Data Base Impact 

The EPD&C reference module and drivers are of moderate impact to the simulation 
data base. The majority of the processing subroutines (data comparison, read, 
write, etc.) would be common to all modules requiring validation. The equipment 
power profiles (time-lines) would be required but represent a minor impact. Data 
files would also be required for the input and output data tables. 
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4.7.5 Environmental Control /Life Support System 

This section includes the discussion of the Atmosphere Revitalization System; 
the Active Thermal Control System; and the Food, Water, and Waste Management 
System. 


4. 7. 6.1 Atmosphere Revitalization System (ARS) 

The ARS includes the Atmosphere Revitalization Pressure Control Subsystem 
(ARPCS), and the ARS Cabin Atmosphere Control Subsystem (ARS-CACS). These tv;o 
subsystems are discussed in the following sections. 
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4. 7. 6. 1.1 Atmosphere Revitalization Pressure Control System Description 

The Atmosphere Revitalization Pressure Control Subsystem (ARPCS) provides 
three basic functions for the Shuttle Orbiter. The functions provided are: 

1) N 2 and O 2 storage (gas) 

2) distribution of gaseous O 2 and N 2 * at proper pressures, to the user 
equipment, system, etc. 

3) ensuring proper Og and N 2 fixture while controlling cabin (crew 
quarters) pressure. 

These functions are accomplished via interconnecting manual valves, solenoid 
valves, pressure regulators, pressure sensors, electronic controls and relief 
valves. This interconnection v;as determined from schematic VL70-000214 (Reference 
111), specification MC250-0002 (Reference 103), and a Preliminary Design Review (PDR) 
handout on the Pov/er Reactant Storage and Distribution System. The resulting 
representative plumbing schematic is shown in Figure 4,7-104 and 4.7-106^ Although 
these figures are not totally accurate, they should suffice for the current 
verification study purposes. 

No Supply and Distribution - The N 2 gas is stored in 3000 psi bottles containing 
approximately 50 pounds of N 2 in each. The primary source of Ng is one (1) 
bottle, with the auxiliary source comprised of three (3) bottles. Additional 
bottles can be carried in the payload area and connected to the system if desired. 
Either the primary, auxiliary, or payload supply can be selected to deliver gas to 
either of the two Ng distribution networks. 

The Ng distribution networks are each comprised of various control valves 
(manual and solenoid) and two (2) Ng pressure regulators. A 175 psi outlet 
regulator provides the proper pressure level to the Og/Ng cabin pressure controller 
and to the potable HgO bottle regulators. This 175 psi regulator also provides 
outlet pressure relief (at approximately 200 psi) to prevent over pressurizing the 
downstream distribution network. The pressure relief is vented overboard resulting 
in possible vehicle attitude and rate disturbance torques. Potable water bottle 
regulators maintain pressurization of the three (3) potable v/ater tanks. Pressure 
is regulated 8 to 12 psi above the cabin pressure. This higher pressure ensures 
the expulsion of the water from the tanks. It should be noted that the Ng side 
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FIGURE ' 1 . 7-1 OB. ATMOSPHERE PRESSURE CONTROL, AIRLOCK SUPPORT SUBSYSTEM SCHEMATIC 
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of the water tanks can be opened to the crew quarters atmosphere via a solenoid 
actuated valve. The potable water tanks pressure regulators also provide pressure 
relief for the water tanks. This relief is vented into the crew quarters and 
contributes to the total cabin pressure. 

Op Supply and Distribution - The Og gas supply has three (3) sources. The primary 
and secondary supplies are from the Cryogenic O 2 Systems for the Power Reactants 
Storage and Distribution System (PRSD) which also provide Og to the fuel cells. 

The Cyrogenic Og flows through restrictor/heat exchangers which provide flow control 
as well as increasing the gas temperature. Oxygen accumulators (surge tanks) act 
as pressure stabilising and intermediate storage devices. 

An auxiliary O 2 gas supply is also available. This is at an initial pressure 
of 3000 psi and must be regulated to approximately 450 psi to prevent over- 
pressurizing the O 2 distribution network. The 450 psi regulator also provides 
a distribution system over pressure relief at approximately 1100 psi. This O 2 
relief is vented overboard and may generate vehicle attitude and rate disturbance 
torques. 

The O 2 distribution networks are each made up of manual valves, solenoid 
valves and a pressure regulator. The 100 psi Og regulator provides the proper 
Og supply pressure to the Og/Ng cabin pressure controller. High pressure Og is 
provided to the four (4) emergency Og outlets in the crew compartment mid section, 
to the four (4) outlets for portable Og bottle filling, and to the two(2) airlock 
support outlets. 

Mixture and Pressure Control - The cabin Og/Ng mixture control and cabin pressure 
control are provided by cabin pressure regulators, pressure relief valves, Og partial 
pressure controller, manual valves, and solenoid valves. 

Og or Ng is selected for cabin make-up gas by the Og/Ng mixture controller. 

The partial pressure of oxygen is sensed by the partial pressure controller and 
electronically opens (for Og partial pressure 3.45 psia) the Ng supply solenoid 
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valve(s) which allows the 170 psi N 2 to flow to the cabin pressure regulator 
Inlet. The Ng pressure is greater than the 100 psi O 2 which feeds the regulator 
through a check valve. The higher pressure closes the check valve preventing 
O 2 from entering the regulator and only is supplied to the cabin. When the 
O 2 partial pressure is less than 2.95 psia, the Ng solenoid valve is closed. This 
allows any cabin make-up gas flow to be Og. Og and Ng sensors provide output 

to the caution and v/arning subsystem if flow is excessive. In addition, signals 
are provided to the caution and warning subsystem if the cabin Og partial pressure 
becomes too high or too low. 

The cabin pressure control is provided by tv;o (2) types of cabin pressure 
regulators, cabin relief pressure valves, and manual valves. The primary cabin 
pressure regulators maintaih the cabin pressure at 14.7 psia under normal conditions. 
However, in the event of excess cabin leakage, additional cabin regulators operate 
to maintain the pressure at 8 psia. 

Two cabin overpressure relief valves operate to limit the cabin high pressure 
at 15.5 to 16 psi above the vehicle external pressure. These relief valves can be 
electrically overridden if desired. Two reverse cabin pressure relief valves 
actuate to maintain a maximum 2 psid external pressure above the cabin pressure. 

These reverse pressure relief valves can be manually overridden when desired. The 
venting of these valves can cause body attitude and rate disturbance torques. 

Manually actuated pressure equalization valves are used to pressurize and 
depressurize the airlock compartment. Each of the three (3) avionics bays is 
continually vented (at a low rate) to the spacecraft external ambient. This 
venting is required to prevent equipment outgassing products from entering the crew 
compartment. The inlet to each bay is open to the crew compartments via a relief 
valve. This valve maintains the bay pressure at 0 to 0.4 psi below the cabin pressure. 
In the event of a cabin rapid depressurization the same relief valve operates at 
0,6 psi to prevent the bay over-pressurizing with respect to the crew compartment. 

A cabin pressure decay rate detection provides signals to the caution and 
warning subsystem when the cabin pressure is decreasing at an excessive rate. 
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The continued venting of the three avionics bays, and pressurization/ 
depressurization of the airlock may cause vehicle attitude and rates disturbance 
torques. 
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ARPC5 Module Functions and Parameters 

Figured. 7-106 provides an overview of the’ ARPC5 simulation module functional 
elements and interfaces with other modules. Basically there are four functions 
performed within the module. These functions are: 

0 Control logic 
0 Og and storage 

e Og and Ng pressure regulation and distribution 
e Cabin pressure control 

Table 4.7-30 provides a detailed listing of the parameters associated v/ith 
the ARPCS module and designation of parameter type. 

The following discussion identifies, in general, the functions performed in 
each element and the factors involved in the calculations. 

Control Logic - The control logic functions are dependent on the position of manual 
I valves, solenoid valves, switches, command Inputs, bus voltages, etc. The logic 
outputs are used extensively in each of the other functional elements calculations. 
The valve logic can be determined from the plumbing schematic; however, the 
electrical logic is not presently known. The total logic will, of necessity, be 
highly dependent on the exact electrical design, and this study does not warrent 
accurate description of the logic. It is only necessary to recognize its existence, 
and the possibility of many combinations existing. 

Og and Ng Storage - The Og and Mg storage functions are the calculation of remaining 
lor available) gas mass, source pressures, temperatures, inlet or outlet mass 
flow, etc. The parameters associated with these calculations are as follows; 

A. Og Accumulator Calculations 

1. Og quantity as a function of initial quantity, inlet flow, outlet 
flow, time, etc. 

2. Pressure as a function of quantity, temperature, tank volume. 

3. Temperature is a function of initial temperature, inlet Og 

>1 tempevature, heat leak, etc. 

4. Mass flow inlet as a function of cryogenic Og pressure, accumulator 
pressure, and restrictor flow/pressure characteristics. 
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TABLE4.7-30.ATN0SPHERE REVITALIZATION PRESSURE CONTROL SUBSYSTEM PARAMETERS 



B9SB1I 

Primary Og Accumulator - inlet 0^ temperature ' 1 

I 

Primary 0^ Accumulator - cryo pi"essure j 

I 

Secondary 0^ Accumulator - inlet temperature j 

I 

Secondary C 2 Accumulator - cryo Gg pressure 

I 

Primary 0^ Accumulator - O 2 mass 

CP 

Secondary O 2 Accumulator - O 2 mass 

CP 

Primary Og Accumulator - Pressure 

P 

Secondary Og Accumulator - Pressure 

p 

Primary O 2 Accumulator - Temperature 

p 

Secondary O 2 Accumulator - Temperature 

p 

Primary O 2 Accumulator - Og inlet mass flow - cryo 

I 

Secondary Og Accumulator - Og inlet mass flow - cryo 

. I 

PRIMARY 'O 2 ’ACCUMULATOR - Og mass outlet flcvf 

p 

SECONDARY Og ACCUMULATOR - O 2 mass outlet flow 

p 

AUXILIARY O 2 TANK - Og mass 

CP 

AUXILIARY O 2 TANK - pressure 

p 

1 AUXILIARY O 2 TANK - Temperature 

p 

AUXILIARY O 2 TANK - O 2 mass outlet flow 

p 

AIRLOCK SUPPORT - O', pressure 

p 

AIRLOCK SUPPORT - O 2 mass flow 

p 

Ng PRIMARY TANK - N 2 Mass 

CP 

N2 AUXILIARY TANKS - Ng mass 

CP 

N 2 PRIMARY TANK - pressure 

p 

N 2 SECONDARY TANKS - pressure 

p 

N 2 PRIMARY TANKS - temperature 

p 

N2 SECONDARY TANKS - temperature 

p 

N 2 PRIMARY ” N 2 mass flow outlet 

p 

N 2 SECONDARY - N 2 mass flow outlet 

p 

Numerous Control Logic Outputs/ Inputs 

p 

Electrical Power System » Bus Voltages 

I 

Aux O 2 regulator - Output Pressure (include relief) 

p 

A'jx O 2 regulator - Input Pressure 

p 

Aux O 2 regulator - Relief vent mass flow rate 

p 
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TABLE 4. 7-30. (CONTINUED) 


PARAMETER 


HID SECTION EMERG Og flow 1 - mass flow 

p 

MID SECTION EMERG 0 ^ flow 2 - mass flow 

p 

MID SECTION EMERG Og flow 3 - mass flow 

p 

HID SECTION EMERG Og flow 4 - mass flow 

p 

PORTABLE 02 bottle fill - 1 bottle pressure 

p 

PORTABLE 02 bottle fill - 2 bottle pressure 

p 

PORTABLE Og bottle fill - 3 bottle pressure 

p 

PORTABLE Og bottle fill - 4 bottle pressure 

p 

PORTABLE Og bottle fill 1 - mass flow 

p 

PORTABLE Og bottle fill 2 - mass flow 

p 

PORTABLE O 2 bottle fill 3 - mass flow 

p 

PORTABLE Og bottle fill 4 - mass flow 

p 

PRIMARY Og - 100 PSI reg - inlet pressure 

p 

PRIMARY Og - 100 PSI reg - outlet pressure 

p 

PRIMARY O 2 “ 100 PSI reg - mass flov/ 

p 

PRIMARY Og - loo PSI reg - relief vent mass flow 

p 

SECONDARY Og - 100 PSI reg - inlet pressure 

p 

SECONDARY Og - 100 PSI reg - outlet pressure 

p 

SECONDARY Og - 100 PSI reg - mass flow 

p 

SECONDARY Og - 100 PSI reg - relief vent mass flow 

p 

PAYLOAD Ng tanks - mass 

CP 

PAYLOAD Hg tanks - pressure 

p 

PAYLOAD Ng tanks - temperature 

p 

PAYLOAD Ng tanks - mass flow out 

p 

PRIMARY Ng 175 PSI reg - inlet pressure 

p 

^ PRIMARY Ng 175 PSI reg - outlet pressure 

p 

PRIMARY Ng 175 PSI reg - mass flow 

p 

PRIMARY Ng 175 PSI reg - relief vent flow 

p 
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TABLE 4.7-30, (CONTINUED). 


— — ; 

PARAMETER 

TYPE® 


SECONDARY N 2 175 PSI reg - inlet pressure 

P 


SECONDARY N 2 1^5 PSI reg - outlet pressure 

P 


SECONDARY N^ 175 PSI reg - mass flov; 



SECONDARY Ng 175 PSI reg - relief vent mass flov/ 

P 


PRIMARY N 2 Check valve - outlet pressure 

P 


SECONDARY Ng Check valve - outlet pressure 

P 


PRIMARY POTABLE H 2 O Bottle Regulator - inlet pressure 

P 


Primary POTABLE H 2 O Bottle Regulator - relief vent flov/ to cabin ' 

P 


PRIMARY POTABLE H 2 O Bottle Regulator - flow rate 

P 


SECONDARY POTABLE HgO Bottle Regulator - inlet pressure 

P 


SECONDARY POTABLE H 2 O Bottle Regulator - relief vent flow to cabin 

P 


SECONDARY POTABLE H 2 O Bottle Regulator - flow rate 

P 


POTABLE H 2 O tank 3 - N 2 (gas) quantity 

CP 


POTABLE H 2 O tank 3 - Gas Pressure 

P 


POTABLE HgO tank 3 - temperature 

P 


POTABLE HgO tank 3 - Gas flovz/bottles 1 & 2 

P 


POTABLE H 2 O tank 3 - Gas volume, 

P 


POTABLE H 2 C tank 3 - H 2 C n^ass remaining 

I 


POTABLE H 2 ^ tanks 1 and 2 - (Gas) mass 

P 


POTABLE H 2 O tanks 1 and 2 - Gas pressure 

P 


POTABLE HgO tanks 1 and 2 - temperature 

P 


POTABLE H 2 O tanks 1 and 2 - Gas flow to cabin 

P 


POTABLE HgO tanks 1 and 2 - Gas volume 

P 


POTABLE H^O tanks 1 and 2 - H^O mass remaining 1 

I 


POTABLE H^O tanks 1 and 2 - HgO mass remaining 2 

I 


Crew Compartment CO 2 Partial Pressure 

P 


Pri N 2 to Cabin Pressure Controller - Pressure 

P 


560.^2 to Cabin Pressure Controller - Pressure 

P 
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TABLE 4.7-39. (CONTxNUED) ' 


^ PARAMETER 

TYPE® 

Pri Og to Cair'n Pressure Controller - Pressure 

P 

Sec Og to Cabin Pressure Controller - Pressure 

P 

Pri Cabin Pressure Regulator - inlet pressure 

P 

Sec Cabin Pressure Regulator - inlet pressure 

P 

Pri Og mass flow to cabin 

CP 

Sec O 2 mass flow to cabin 

CP 

Pri 1^2 mass flow to cabin 

CP 

Sec ^2 cabin 

CP 

Pressurized Volume 

p 

Crew Compartrent Pressure'- total 

p 

Crew Compartment Pressure - Og Partial Pressure 

CP 

Crew Compartment Pressure - Decay rate 

CP 

Crew Compartment - O 2 mass 

p 

Crev/ Compartfi'.ent - No mass 

p 

Crew Compartment - temperature (gas) 

I 

Crew Compartment - O 2 leakage, loss 

p 

Crew Compartment - N 2 leakage, loss 

. p 

Airlock Compartment - O 2 mass 

p 

Airlock Compartment - N 2 mass 

p 

Airlock Compartment - Pressure 

p 

Airlock Compartment - O 2 mass loss /gain 

p 

Airlock Compartment - N 2 mass loss/gain 

p 

Payload Coinpartment - O 2 mass 

p 

Payload Compartment - Ng 

p 

Payload Compartment - Pressure 

p 

Payload Compartment - Og mass loss/gain 

p 

Payload Compartment - N 2 mass loss/gain 

p 

Avionics Lay 1 - O 2 mass 

p 

Avionics Day 1 - Ng mass 

p 

_,__7.^onics Day 1 - Pressure 

p 


oowct/is -QSSTfsOA/y^ejTjcs coMPArj\’ - 
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P = Performance Parameter 

CP = Critical Performance Parameter 
I = Input parameter (from another module) 
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B. Auxiliary Calculations 

1. O2 quantity remained as a function of time, initial quantity, flow, etc. 

2. O2 source pressure as a function of quantity, temperature, tank volume. 

3. Temperature as a function of initial temperature, heat leak, etc. 

C. N2 Source Calculations 

1. Primary, auxiliary, and payload N2 quantities as a function of 
initial quantities, outlet flow, etc. 

2. Primary, auxiliary and payload temperature as a function of initial 
temperatures, heat leaks, etc. 

3. Primary, auxiliary and payload source pressures as a function of 
temperature, tank volumes, quantity, etc. 

D. Components characteristics needed to perform these calculations are: 

1. Cryogenic O2 restrictor/heat exchanger O2 flow versus differential 
pressure characteristic. 

2. accumulator volumes 

3. O2 and N2 tank volumes 

Pressure Regulation and Distribution - The O2 and N2 pressure regulation and 
distribution functions are the calculation of the pressures, temperatures, flow 
rates, etc, throughout the distribution networks. The parameters associated with 
the calculations are as follows: 

A. Og Distribution Network Calculations 

1, Gas temperatures as a function of source temperature and heat leaks. 

2, Pressures as a function of regulator characteristics, inlet 
pressures, relief characteristics, line volumes, flow rates, etc. 

3, Total system flow rate as a function of demand, leakage, etc. 

4, Og delivery flow rates to the four Emergency O2 outlets as a function 
of inlet/outlet pressures, vO ve/line flow characteristics, 

5, O2 delivery flow rates to '^ne four portable O2 fill outlets as a 
function of inlet/outlet pressures, fill tank volume, valve/line 
flow characteristics, etc. 
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I B. N 2 Distribution Network Calculations 

I" 1. Temperatures as a function of source temperatures' and heat leaks. 

2. Pressures as a function of regulator characteristics, inlet 
pressures/relief characteristics, line volumes, flow rates, etc. 

3. Total system flow rate as a function of demand, leakage, etc. 

4. Ng gas flow rate and quantity delivered to the potable water tanks 
as functions of regulator characteristics, H^O tank Ng volume, 
remaining HgO quantity, etc. 

5. Ng gas flow to cabin via the valve opening the HgO tanks Ng side 
to cabin. 

C. The component characteristics needed to perform these calculations are: 

1. Pressure regulators flow characteristics, relief pressure points, 
and regulation pressure points. 

2. Line/equipment volumes. 

Cabin Pressure Control - The cabin pressure control functions are the calculation 
of various compartment pressures, Og and Ng gas quantities, g flow rates into 
and out of the cabins, and pressure decay rates. The parameters associated with 
these calculations are as follows: 

A. Flow Rates 

1. Og flow rate to cabin as function of pressures, partial pressure 
controller characteristics, cabin pressure regulator characteristics , 
etc. 

2. Ng flow rate to cabin as function of pressures partial pressure 
controller characteristics, cabin pressure regulator characteristics. 

3. Og and Ng flow from cabin, as function of pressures, cabin leak 
rates, relief valves, depressurization valves, etc. 

B. Gas Quantities 

1. Og and Ng quantities in cabin as a function of initial quantities, 
flow rates into and out of cabin, etc. 

,l 
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C. Cabin Pressure 

1. Caution and warning signals as functions of pressures. 

2. Cabin pressures as a function of various gas partial pressures, 

3. Og partial pressure as a function of O 2 quantity, cabin temperature, 
cabin volumes. 

4. partial pressure as a function of N 2 quantities, cabin tempera- 
ture, cabin volumes. 

D. Component characteristics required to perform these calculations are: 

1. Cabin pressure regulators flovVpressure characteristics, regulation 
points, etc. 

2. Cabin pressure relief valves flow/pressure characteristics, open and 
close points for solenoid valves. 

3. O 2 partial pressure controller operating voltage levels, open and 
close points for solenoid valves. 

4. Avionics bays vent orifice flow/pressure characteristics (effective 
flow area), etc. 

5. Airlock vent and equalization valve flow/pressure characteristics. 

6. Cabin or compartment gas volumes, leakage, etc. 
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ARPCS Reference Data Sources and Formats 

Reference modules for ARPCS module validation can be developed from routines 
described in Reference 101 and 102* The G189A (see Ref, 12 ) program was developed 
for JSC and provides a versatile analytical tool for support of environmental 
systems work. Reference 102 describes environmental analysis subroutine used for 
mission analysis and consumables studies. 

Figure 4.7-107 is a flow chart for calculation of gas flow into or from a 
manifold or compartment from various sources, as well as calculating the resulting 
pressure, temperature, etc. This routine is used in providing a reference module 
for cabin pressure control (see Figure 4.7-100) and ^2 distribution/source 
(Figure 4, 7-lon). The O 2 distribution network module can be developed in a 
similar way. It should be noted that the proper system control logic must be 
integrated into these modules. 

The system and component design performance requirements, analysis, performance 
predictions, and test results provide data for direct comparison with the Shuttle 
simulation results. Reference 22. will provide these types of data as they become 
available. The design requirements can be determined from Reference 103. 
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FIGURE 4.7-103, (CONTINUED) 
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R. “ Crew Compartment Pressure 
fi " Lock Compartment Pressure 
Payload Compartment Pressure 
Avionics Bay 1 Pressure 
Jsi. - Avionics Bay 2 Pressure 
Pgs" Avionics Bay 3 Pressure 

- Ambient Pressure 
Ambient Temperature 

Compartment heat exchanger outlet temperature 
t - Crew Compartment Temperature 
71 - Loci Compartment Temperature 
~ Payload Compartment Temperature 
T^f ~ Avionics Bay 1 Temperature 
Tsi. " Avionics Bay 2 Temperature 
Tbs " Avionics Bay 3 Temperature 

At ~ Effective flow area of relief valves, lines, etc., between compartments 

- Heat gain rate of crew compartment 

• 

- Heat gain rate of lock compartment 

(Sp - Heat gain rate of Payload compartment 

Qjj, - Heat gain rate of Bay 1 compartment 

Heat gain rate of Bay 2 compartment 

^£3 - Heat gain rate of Bay 3 compartment 

<?£te-cT-cj“ Electrical heat rate for compartment 
j “■ Heat leakage rate from compartment 
“ Metabolic heat rate 

- Compartment volume 

" Constant pressure specific heat of gas 
Cy ^ Constant volume specific heat of gas 

- Gas Constant 

Y - Specific heat ratio of gas 

Gas flow rate into compartment ('P ) from compartment y 
“ O 2 gas flow rate into compartment r from compartment y. 

~ N 9 gas flow rate into compartment from compartment y. 

- CO 2 gas flow rate into compartment from compartment y. 

“ HgO gas flow rate into compartment 7^- from compartment y. 

FIGURE 4.7-nT. ( CONTI flUED) 
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X compartment O 2 gas quantity 
- X compartment ^2 gas quantity 
compartment CO 2 gas quantity 
compartment H 2 O gas quantity 


4t. 


FIGURE <l.7-r^8 (CONTINUED) 
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LEGEriD: 

Pufc .1 “ Cabin Pressure Regulator inlet pressure 

- Cabin Pressure (Crew Compartment) 

^ 2 -, - O 2 Regulator (100 psi) outlet pressure 
" N 2 170 psi Regulator outlet pressure 
Prfzo-(~H 20 tank regulated pressure 
Pjz-si'' N 2 170 psi Regulator inlet pressure 

■Jfi - Cabin temperature 

“ Cabin pressure regulator inlet temperature 
T;>z .-;.7 ~ Ng 170 psi pressure regulator inlet temperature 
~ H 2 O tank gas temperature 
" N 2 170 psi regulator inlet temperature 
" Cabin pressure regulator inlet manifold volume 
li/jo-r Volume of H 2 O in H 2 O tank 
Vr " Volume of HgO tank 

VOz-si “ Volume of manifold inlet to N 2 pressure regulator 
regulator outlet volume 

/?/?£■£,/ “Effective flovy area of cabin pressure regulator 

Effective flov/ area of H 2 O tank pressure regulator 

- Specific heat at constant pressure 

- Specific heat at constant volume 
Specific heat of liquid water 

v4t><:oi)-02 flow rate into cabin 
~ N 2 i^low rate into cabin 
flow rate of N 2 170 psi regulator 
H 2 O flow rate into H 2 *^ 

H 2 O flow rate out of H 2 O tank 
H 2 quantity in H 2 O tank 

Cabin pressure regulator inlet line O 2 mass quantity 
Cabin pressure regulator inlet line ^2 mass quantity 
” *"* 2 ^ 9^^ quantity 

regulator inlet quantity 

FIO'JRE (CO.rrifiUFD) 


McrffifvrvrLi » cast 
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■r- Specific heat ratio (CP/CV) 
Gas constant 


FIGURE A. 7-109 (CONTI, lUED) 
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LEGEND: 

- Tank pressurf; 

Ambient pressure 

Effective flow area of relief line/valve 
T<, ~ Temperature of tank 
■^“Tank compartment temperature 
-jriae-Flow rate through relief line 
'^so-Flow rate to distribution system 
Quantity of gas in source tank 
^ 50 - Gas density in tank 
Wrf 7 v?^-Tank electrical heater power 
Heat leak into tank 

- Gas specific heat 

— Tank volume 


FIGURE ^.7-lV’. (CONTinUFD) 
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ARPCS Validation Methods and Check Cases 

The verification approach for the ARPCS simulation module utilizes aud expands 
upon the technique presented in Section 5-1 , The use of this flow chart 

allows the comparison of the simulation module with various types of chockcases 
(test, analysis, software model, etc.). FigureA. 7-112 presents the flowchart for 
checkpoint generation subroutine in Figure 5.1-1 Figure A. 7-1 13 is the sub- 
subroutine shown in Figure 4.7-112 as "COMBCHK" and generates the "all checkpoints 
sequenced" flag. 

Some liberty was taken in the notation for variables in these flow charts. 

With the exceptions of time (t), initializatior, time (to), computation time ( At), 
and COMBCHK variables, the variables used represent a group or "set" of parameters 
rather than a single variable. Each parameter set is associated with a particular 
driver, function or logic. For example, the variable PAOS (JAOS) represents a 
set of parameters including pressure, O 2 quantity, etc. associated with the 
auxiliary O 2 supply. The identification of the actual parameters is dependent 
on exact system design and simulation fidelity desired. 

This verification technique provides the following capabilities; 

0 Initialization of parameters 
0 Interfacing module drivers 
0 ARPCS functional element drivers 
0 Time-dependent evaluations 
© Multiple evaluations in a single run. 

Ini tializatiun - At the start of each checkcase the ARPCS module and driver 
parameters, logic, and conditions are set to pre-determined values. The values 
may change as the checkcase is allowed to continue. 

External Module Drivers - The parameters normally provided by interfacing modules 
are provided by module drivers. These drivers supply parameter values vjhich 
can be held constant or allowed to vary according to calculations performed 
within the driver. The following module drivers were identified; 
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GENPT- 

ARPCS. 


t = t +At 


/LHIT JCRY 
^HIT JATC 
EMIT JCLHT 
LHIT JH20 
LHIT JLTRC 
EMIT JFIR 
LHIT JAOS' 
LHIT JN2S 
LHIT JCBKP 
LHIT 0M2L 
LHIT J02L 
LHIT JCBNL 
LHIT 002H 
LHIT JM2K 


PCRY (JCRY) 
PATC (JAfC) 
PCLRT (JCNT) 
PH20 (JH20) 
PLTRC (JLTRC) 
PFIR (JFIR) 
PADS (JAOS) 
PN2S (JN2S) 
PCbHP (JCBNP) 
CM2L (JK2L) 
C02L (J02L) 

CP CL (JCBflL) 
D02IC (J02N) 
DN2IC (JN2N) 


CRYIC (JCRY) 
ATCIC (JATC) 
CLUTIC (JCLNT) 
H20IC (JH20) 
ELPIC (JLTRC) 
FSIC (JFIR) 
AOIC (JAOS) 
SH2IC (JN2S) 
CPIC (JCBNL ) 

tLMIt 

At 

to 


CRYO STATIC FLAG 
ATC STATIC FLAG 
CENT STATIC FLAG 
H20 STATIC FLAG 


LTRC STATIC FLAG 
FIR STATIC FLAG 
AOS STATIC FLAG 
M2S STATIC FLAG 


CBRP STATIC FLAG 



JCRY 

= 1 

JCBHP = 1 

JATC 

^ 1 

JN2L = 1 

JCLNT 

== 1 

J02L = 1 

0H2O 

= 1 

JCBNL = 1 

JLTRC 

= 1 

J02N = 1 

JFIR 

= 1 

JN2N = 1 

JAOS 

= 1 

t = to 

JN2S 

= 1 

CHKPSEQ FLAG= CLEAR 


CGHbCHK 
(GENERATE 
JCRY, JATC .. 

/ CLEAR 

^ ^/XHKPSEOV.. 



t = to 



...JN2n) 

JSET 



RETURN 


FIGURE 4.7-112, CHECK FTINT DRIVER, ATMOSPHERE REVITALIZATION PRESSURE CONTROL 
SUPSYSTU1 (ARPCS) FLOWCHART 
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I- 

I', 


CRYO 2 SOURCE INJIAL COMDITIOMS 
ACTIVE THERMAL C 3MTROL INITIAL CONDITIONS 
H?0 COOLANT INITIAL CONDITIONS 
POTABLE H20 INITIAL CONDITIONS 
ELECTRIC POWER INITIAL CONDITIONS 


CRYIC (JCRY) 
ATCIC (JATC) 
CLNTIC (JCLNT) 
H20IC {JH20) 
ELPIC (JLTRC) 


FIRE SUPPRESSION INITIAL CONDITIONS 
AUX 02 SOURCE INITIAL CONDITIONS 
N2 SOURCE INITIAL CONDITIONS 
CABIN PRESSURE CONTROL INITIAL CONDITIONS 
N2 CONTROL LOGIC 


:FSIC (JFIR) 
AOIC (JAOS) 
N2S1C (JN2S) 
CPIC (JCBNP) 
CN2L (JN2L) 


02 CONTROL LOGIC 
CABIN PRESSURE CONTROL LOGIC 
02 DISTRIBUTION NETWORK INITIAL CONDITIONS 
N2 DISTRIBUTION NETWORK INITIAL CONDITIONS 
ACTIVE THERMAL CONTROL PARAMETERS 


C02L (J02L) 
CPCL (JCBNL) 
D02IC (J02N) 
DN2IC (JN2N) 
PATC (JATC) 


CRY 02 PARAMETERS 
H2D COOLANT PARAMETERS 
POTABLE H20 PARAMETERS 
ELECTRIC POWER PARAMETERS 
FIRE SUPPRESSION PARAMETERS 


PCRY (JCRY) 
PCLNT (JCLNT) 
PH20 (JH20) 
PLTRC (JLTRC) 
PFIR (JFIR) 


AUX 02 SOURCE PARAMETERS 

N2 SOURCE PARAI4ETERS 

CABIN PRESSURE CONTROL PARAMETERS 


PADS (JAOS) 
PN2S (JM2S) 
PCBNP (JCBNP) 



ji 


■ t ' 








f . j 


i: 


U 

f 


ACTIVE THERMAL 

CONTROL 

MODULE 

INTERFACE 

DRIVER 




ACTIVE 

THERMAL 

CONTROL 

PARAMETER 

CALCULATIONS 



ACTIVE TfiERi;/2 
CONTROL 

PARAMETERS = [ 
PATC (JATC) ; 








FIGURE /1. 7-112( CONTINUED) ^.7-ri 
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PRS&D MODULE i 
CRYOGENIC 02 | 
INTERFACE ; 
DRIVER 



CRY 02 

PARAMETERS 

CALCULATIONS 


ARS MODULE 
K20 COOLANT 
INTERFACE 
DRIVER 


CLKT 

STATIC 


H20 COOLANT 

PARAMETERS 

CALCULATION 


CRY 02 

PARAMETERS = 
PCRY (JCRY) 





H20 COOL I ANT 
PARAMETERS = 

PCLNT (JCLNT) 


POTABLE H20 
MODULE 
INTERFACE 
DRIVER 


POTABLE H20 
PARAMETERS j 
CALCULATIGHSi 


POTABLE tl20 
PARAMETERS = 

PH20 (JH20) 


© 


FIGURE 4.7-112 (continued) 


4. 7-1^2 













W2 SOURCE i 
DRIVER h 



FIGURE 4.7-nn (CONTinUED) 
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CAB IK 
PRESSURE 
CONTROL 
DRIVER 


N2 SOURCE 
PARAMETERS = 
PN2S (0N2S) 



CABIN PRESSURE 
CONTROL 
PARAMETERS = 
PCBNP {JCDNP) 


/I ^ i 

/V7000ft/A/i?£-IL. » C='^ST“ 
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LEGEND: 


to 

= 

Universal time at Initialization 

At 

= 

Computation time 

tCMIT 


Limit on time 

CMIT 

= 

Limit 

CRY 


Cryogenic element 

ATC 

= 

Active Thermal Control Element 

CLNT 

= 

Coolant element 

H20 

= 

HgO element 

LTRC 

= 

Electric element 

FIR 

- 

Fire Suppression element 

AOS 

= 

Auxilliary Og element 

N2S 

= 

Ng source element 

CBNP 

= 

Cabin Pressure element 

N2L 

:= 

Ng logic element 

02L 


Og logic element 

CBNL 


Cabin Logic element 

02N 

= 

Og network element 

N2N 

= 

Ng network element 

J 

= 

Indexing variable for indicated parameters 

^rc 

= 

Indicated parameter initial conditions 

p 

= 

Parameters for indicated element 


FIGURE 4.7-112 (COMPLETE) 
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COMBCHK 


-^JCRY 
>LMIT 
V. JCRY, 


JCRY = 1 


/ JATC\,NO 
>IHIT 
\JATC/ 
N^YES 


JATC = 1 ; 


NO’ JCRY = 

' JCRY + 1 


JATC = 
JATC + 1 



y^CU'n\ NO 1 JCLHT = 
>LWIT >W^^iJCLKT + 1 

■\jclntX ' 

YES 


JCLMT = 1 


/JFIR 

>LMIT 

Xjfir. 


JFIR = 1 
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JFIR = 
JFIR + 1 


/JAGS ^ 
> LIMIT 
VJAOS^ 


JAOS = 1 


NO ^fJAOS=' 
^JAOS + 1 


JN2S = 
JN2S + L 



JM2S = 1 


rJH20 = 

>Li'UT JH20 + 1 

Xj'20; / 


JCBNPX rn 

JCBNP”^ I 

Hjcbkp + 1 > 


JH20 = 1 


JCENP = 1 


/ Jl.TRC\ No 

>IHIT >-^^JLTRC = 
VJLTRC/ iJLTRC + 


r 1 

, 


^N2C\ NO 

>LMIT = 

\ JN2L / JN2L + 1 


1 

V . 

s . 


JLTRC = 1 
- 

( 1 .... 


RLTUfU'i 


_.Y . 

JN2L = 1 


■ FIGURE 4.7-113, FLOWCHART FOR ARPCS CHECKPOINT SEQUENCE 
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FLAG = SET 
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{See Figure 4.7-113») 
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e PRSD CryDgenIc Og supply - provides Og supply pressure temperature, 
quantity, etc. 

d Active Thermal Control - provided cryogenic 0^ temperature, etc. 
e ARS-HgO Coolant - provides cabin temperature, CO2 quantity, humidity, 
etc. 

0 Potable H2O Management - provides quantity H2O remaining (each tank), 
temperature, etc, for Ng pressure quantity, etc. calculations. 
e Electrical Power Distribution - provides bus voltages for logic, etc. 
e Fire Suppression - provides freon quantity release rate into cabin 
for cabin pressure calculations, etc. 

Functional Element Drivers ~ Certain intramodule parameters provide logic changes, 
etc, which require thorough verification. Drivers are included to provide ease in 
this verification. Those drivers identified were: 

© Auxiliary Og source - parameters include tank pressure, quantity, etc. 

0 Ng source - parameters include tank pressures, quantities, etc. 

® Cabin pressure control - parameters include cabin total pressure, 
pressure decay rate, Og partial pressure, etc. 

Multiple Evaluations - The sub-subroutine "COMBCHK" (Figure 4.7-113) generates the 
values of indexing variables controlling the checkcase conditions and determin'es 
when all check points have been sequenced (CHKPSEQ). Since the number of check- 
cases performed during a single run is the product of the number of parameter 
sets (EMIT dCRY, etc.), care must be taken to prevent a large number of unnecessary 
checkcases being performed. Effort must be made to complete the module verifi- 
cation with a minimum number of checkcases. This may be best accomplished by 
restricting certain parameter sets to nominal values, while cycling through the 
more significant parameter sets. The run could then be repeated for different 
parameter sets. 
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ARPC5 Data Base Impact 

The major impact to the ARPCS date base is the impact of the reference module 
(Figures '1.7-107, 4.7-100, and 4.7-109] and the functional element/module drivers of 
Figure ^-7-11 2. [viost processing subroutines (data input/output routines) would be 
common to all modules being validated. Data files are required for storage of the 
output data tables. The use of analysis/test/design requirements as reference 
data requires the use of special drivers. These drivers establish and maintain the 
conditions within and interfacing with the module which correspond to the analysis/ 
test/design conditions. The plotting or formatting of the simulation results 
would require a few utility subroutines of small data base impact. 
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4. 7. 6. 1,2 ARS-CACS Subsystem Description 

The ARS Cabin Atmosphere Control Susbystem provides the circulation of the 
atmosphere, temperature and humidity control, and COg and odor control. Figure 

4.7-114 provides a simple schematic of the interfaces with other ECLSS modules. 

Atmosphere Circulation - This subsystem provides atmosphere circulation for the 
crew quarters, and avionics bays. A simple schematic of the crew quarters circula 
tion 1s shown in Figure 4. 7“1 15 and the avionics bay schematic is shown in Figure 

4.7-116. 


Temperature Control - This element provides cooling and heating of the cabin 
atmosphere. Thermal transport is accomplished by means of two water loops, as 
shown in Figure 4.7-116. The primary and secondary loops are identical, except 
that the secondary loop has one water pump vice two as in the primary loop. 

Heat rejection from the water loops to the ATCS is accomplished at the cabin 
interchanger through which both water loops and both ATCS freon loops flow. Two 
water sublimators receiving water from the potable water system provide an active 
heat sink during launch and orbital periods when the payload bay doors, housing 
the space radiator system on the underside, are closed. The sublimators are 
active during entry to an altitude of lOOK feet.. Between 100K feet and 20K feet 
there is no active heat rejection from the Orbiter, and temperatures are governed 
by the bulk thermal capacitance of the vehicle. Below 20K feet through landing, 
ammonia evaporators in the ATCS are activated for heat rejection. 

Figure 4.7-115 from Reference 23 shows the Orbiter cabin atmosphere thermal 
and purification system. Three fans circulate cabin air through an aerosol filter, 
through lithium hydroxide canisters for CO, removal, then on through a condensing 
(cooling) heat exchanger for temperature and humidity control. Condensate is 
removed to the waste management system. The condensing heat exchanger is part of 
the water coolant loop system shown as the "cabin HX“ in Figure 4,7-114. The 
cabin temperature is maintained by controlling the airflow through the cabin heat 
exchanger by means of a controller regulating bypass flow around the heat exchanger. 
The controller is regulated by a temperature selector. If cabin heat input is 
required the controller activates electric heaters in the bypass loop. 
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ARS-CAC5 Module Functions and Parameters 

Figure 4.7-117 provides an overview of the ARS-CACS simulation module 
functional elements and interfaces with other modules. There are five basic 
functions performed within the module: air circulation, CO 2 /H 2 O control, H 2 O 

coolant flow, thermal control, and control logic. Tables 4,7-31 , 4. 7-'12 , and 
4.7-33 provide a listing of the atmosphere control module parameters. The 
following discussion is related to the calculations performed within each of the 
module elements. 

Air Circulation - Air circulation calculations are provided for each of the three 
avionics bays and the crew quarters. 

0 Fan/Duct flow rates - These are functions of input voltages, air density, 
duct pressure drop and fan efficiency. 

© Duct pressure drop - a function of air velocity, density, and duct 
configuration or branches. 

0 Condensate line inlet pressure - a function of pump outlet pressure and 
duct pressure drop. 

D Duct air temperature - functions of cabin temperature, duct velocity, 
fan power, heat exchanger outlet temperature, air cooled equipment 
electrical power, and electrical heaters electrical power. 

CO 2 Control _ control is provided for the crew quarters. 

e CO 2 removal rate - a function of cabin CO 2 pressure, air flow rate through 
Li OH canisters, and air temperature. 

HgO Coolant. Loop Flow ^ Calculates HgO coolant loop flow rates and pressures. 

0 Pump flow rate - a function of input voltage, pump pressure rise, and 
inlet pressure. 

0 Loop pressure drop - a function of H 2 O pump flow rate, H 2 O temperature, 
and branch flow rates. 

6 Branch flow rates - functions of pump flow rates and cabin heat exchanger 
outlet HgO temperature. 

0 Accumulator H^O Quantity - a function of H 2 O temperature, 

e Accumulator Pressure - a function of H 2 O quantity and temperature. 


4.7-374 


mcooNKEiLt. oou'ajLAS At.s-TETOPJAtJ'racs cowspaivv m e/isr 


-1-S&3 ■ A,rJVds/uoi^ si>sj.rsvrj<aujL.sv sw/Eanoo ~3ii3AfnjGtjOLAJ 


■ U 




I 

cn 


£y 


V 
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TABLE 4.7-31 WATER COOLANT LOOP MODEL INPUT DATA 


PARAMETER 

TYPE^ 

SPECIFIC HEATS 

DB 

HEAT TRANSFER COEFFICIENTS 

DB 

SOURCE HEAT CAPACITIES 

DB 

SOURCE TEMPERATURES 

DB 

LOOP TEMPERATURES 

DB 

INTERNAL HEAT LOADS 

DB 

TRAJECTORY AND ATTITUDE HEAT LOAD TABLES 

DB 

TRAJECTORY AND ATTITUDE 

I 

MISSION PHASE FLAGS 

I 

WATER PUMP/LOOP FLOW CHARACTERISTICS 

DB 

INTERFACING MODULE PARAMETERS 

I 

WATER PUMP POWER 

DB 

AVIONICS EQUIPMENT POWERS 

DB 

AVIONICS BAY FAN/ATR FLOWRATE CHARACTERISTICS 

DB 

AVIONICS BAY FAN POWER 

DB 

WATER PUMP AND AVIONICS BAY FAN ON-OFF DISCRETES 

I 

AVIONICS EQUIPMENT ON-OFF DISCRETESC 

I 

POTABLE WATER USAGE 

I 

SUBLIMATOR OPERATING CHARACTERISTICS 

DB 

LIQUID COOLED GARMENT HEAT LOADS 

DB 


a DB - from Data Base 


I ~ Input 
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TABLE 4.7-32 WATER COOLANT LOOP MODEL OUTPUT DATA 


PARAMETER 

TYPE^ 

H20 accumulator QUANTITY - PC L a SC L 

P 

AVIONICS BAY 1 AIR FLOW 

P 

AVIONICS BAY 2 AIR FLOW 

P 

AVIONICS GAY 3 AIR FLOW 

P 

SUGLIMATOR OUTLET TEMP - PCL A SCL 

CP 

HpO COOLANT FLOW RATE - PCL a SCL 

P 

SUBLiriATOR 1 VAPOR VENT TEMP 

P 

SlIBLIMATOR 2 VAPOR VENT TEMP 

P 

PUMP OUTLET PRESSURE - PCL a SCL 

P 

AVI Of i ICS BAY 1 OUTLET TEMP - PCL S SCL 

CP 

AVIOfllCS BAY 2 OUTLET TEMP - PCL a SCL 

CP 

AVIONICS BAY 3 OUTLET TEMP - PCL a SCL 

CP 

CABIN INTERCHANGER OUTLET TEMP - PCL a SCL 

CP 

SOURCE TEMPERATURES {ALL CAPACITIVE LOADS) 

p 

LOOP TEMPERATURES (NOM-TELEffETERED) - PCL A SCL 

p 

aOW PATES (NOM-TELEMETFRED) - PCL a SCL 

p 

HEAT TRANSFER RATES (NON-TELEMETERED) - PCL a SCL 

p 

PUMP OUTLET TEMP - PCL & SCL 

CP 


a P - Performance Parameter 

CP - Critical Performance Parameter 
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TABLE 4.7-33, CABIN ATMOSPHERE PERFORMANCE PARAMETERS 


H i 
■' ! 


PARAMETER 

TYPE^ 

METABOLIC HEAT, COj, AND IJATER PRODUCTION 

DB 

CABIN EQUIPflENT HEATING RATES 

I 

TRAJECTORY/ATTITUDE CABIN HEATING RATES 

i 

CABIfi FAH PERFORMArtCE DATA 

DB 

CABirj FAN ON-OFF DISCRETES 

P 

Li OH CANISTER ON-LINE TII€ 

P 

LiOM CANISTER PERFORMANCE CHARACTERISTICS 

DB 

TEMPERATURE SELECTOR SETTING 

P 

BULK CABIfi THERMAL CAPACITANCE 

DB 

rOMDENSING HEAT EXCHANGER CHARACTERISTICS 

DB 

CONTRCILLEP/BYPASS THROTTLE CHARACTERISTICS 

DB 

CABIN TEMPERATURE 

CP 

CABIN HUMIDITY 

CP 

CABIN CO^ PARTIAL PRESSURE 

CP 

CABIN AIR FLOW RATE 

CP 

OUTLET HUMIDITY 

P 

OUTLET COp PARTIAL PRESSURE 

P 

OUTLET TEIPERATURE 

CP 

CONOENSIHG Hx AIR FLOW RATE 

P 

CONDEMSING Hx OUTLET AIR TEMPERATURE 

P 

■ , . . 


a P - Performance Parameter 

CP - Critical Performance Parameter 
I ~ Input 
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Thermal Control - Temperature calculations are provided for the HgO coolant loops 
and interfacing module. 

D Pump outlet temperature - a function of HgO flow, pump inlet temperature, 
pump pressure rise, and pump input electrical power. 

0 Col dpi ate equipment temperature - functions of electrical pov;er, inlet 
H 2 O temperature, equipment temperature, and H 2 O flow rate. 

© Heat exchanger outlet H 2 O temperatures - functions of inlet HgO 

temperature, H 2 O flow rate, interchange fluid inlet temperatures, and 
interchange fluid flow rate. 

e Heat exchanger outlet interchange fluid temperatures - functions of 
interchange fluid inlet temperature and flow rate and the HgO inlet 
temperature and flow rate. 

0 Accumulator H-r,0 inlet temperature - a function of cabin heat exchanger 
outlet H 2 O temperature/flow rate, bypass temperature and flow rate. 

© Pump inlet temperature - a function of the accumulator inlet temperature, 
accumulator temperature and HgO flow rate. 

ARS-CACS Reference Data Sources and Data Format 

Various reference data sources exist for the ARS- CACS. Data concerning 
component and system performance requirements, predictions, and tests are 
available from References 22 and 104. In addition, several computer programs are 
available for development into a reference model or performing analyses. 

References 12 and 102 described component subroutines v/hich can be combined to 
provide a system simulation reference module. Reference 105 is an ARS/ATCS 
performance routine designed for use v/ith the Wang 700-series programmable 
calculator system. The use of this type of equipment allov/s an average runs 
time of five minutes per case, as opposed to hours or days turnaround with a 
regular computer facility. References 106 and 107 provide data for Orbiter heat 
exchanger calculations. The following discussion pertains to the development 
of a independent reference module. 
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Pinal performance evaluation of the simulator subsystems modules is best 
accomplished by evaluating the dynamic response of all crew station displayed and 
telemetered parameters pertaining to that subsystem, in a full -up simulation (all 
interfaces operating ) of a mission phase or a transition from one mission phase to 
another. Certain parametric data, other than displayed data, is required to 
verify proper interfacing and coupling with other subsystem modules, e.g., the heat 
load from the H 2 O coolant loops transferred to the ATCS. 

Static check cases can be run with simpler verification models, however, the 
validation of simulator response to combinations of off-nominal operating con- 
ditions, insertion of malfunctions, etc., is not readily performed using simple 
check case models. The subject thermal and atmospheric control models are 
presented as examples of what a verification model involves in terms of input 
data and interface requirements. Maximum use should be made of existing hardware 
sizing and subsystem analysis programs with their data packages in developing an 
integrated verification module, e.g.. Reference 12. 

Primary and Secondary H 2 O Coolant Loop Model - The math flow for the H 2 O coolant 
loops model (COOLP) is shown in Figure 4. 7-HB . This model is applicable for 
generating static or programmed parametric variation check case data from a 
given set of input data, as well as generating performance data from a dynamic 
simulation run (whereby the simulator supplies the systems configuration and 
trajectory data). Basically COOLP calculates the outlet temperature of each heat 
transfer device in the order of the device position in the loop. Appropriate 
mixing calculations are performed at device output ccnvergence points. Reference 
is made to three subroutines for calculating outlet temperatures for three types 
of heat transfer devices: a) col dpi ate, b) heat exchanger, and c) a direct 
heat load such as structural cooling, v/indows, etc. 


COOLP uses an incremental time base for the computations. Typically the 
time increment would correspond to the computation cycle of the simulator module 
being checked. The device inlet temperature is related to the preceeding device 
outlet temperature and assumed constant during the integration time period. 
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The PRI and SEC H 2 O loops are identical except for flow rate, i.e., all heat 
transfer devices are serviced by both loops. The model combines the flow in both 
loops, and the calculated loop temperatures are applicable for both loops. 

Parameters for a non-operating loop could be set to some predetermined value based 
on the temperaturer maintained by the operating loop. 

The comp cycle begins at the outlet of the HgO pumps and proceeds around the 
loop as shown in Figure 4. 7-llR using internally calculated flow rates and heat 
loads as applicable. Not all the coolant loop flow paths are represented fo*' the 
sake of simplicity, e.g., the avionics bay cold plates really consist of a series/ 
parallel arrangement of cold plates for each piece of equipment. Some unidentified 
functions are those of the cabin interchanger bypass flow which is controlled fay 
the cabin HX outlet temperature, and the sublimator operation. 

Table 4. 7-31 is a representative set of input data required to operate COOLP. A 
complete set of starting conditions is required including load source and loop 
temperatures. Data pertaining to vehicle and subsystem configuration is contained 
in a configuration array of discretes which is continuously updated during the 
course of a run. These data are used to internally compute flow rates and heat 
loads from tabular type input data. Anumberof scripted malfunctions can be 
handled by inputs to the configuration array. 

Operational data such as heat capacities, heat transfer coefficients, etc., 
will probably not be available until late in the subsystem design/ test stage; 
hov/ever, high fidelity data of this type is not required for accurate equilibrium 
solutions. Starting conditions (namely initial loop temperatures , bypass flow 
rates, etc.) can be determined and trimmed by running the model until it reaches 
equilibrium for given static heat loads and vehicle configuration. 

The output parameters for directly evaluating the performance of the H 2 O 
coolant loop module are lis-ed in Table '^.7-33. All the telemetered parameters 
are available for display on any of four crew station CRT's via keyboard callup. 

Other parameters (such as avionics equipment case temperatures) can be checked 
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using this model; however, they are not identified here. The output from COOLP 
can be used to provide checks on such things as equipment overtemp condition 
sensing and proper alarm response. Parameters such accumulator quantities are 
scripted unless a malfunction such as a leak is input, whereby internal compu- 
tations would be made prior to outputting the data. 

Cabi n Atmosphere Control - The math flow for the cabin atmosphere control model 
(CABAIR) is shown in Figure 4.7-119. As with COOLP this model is capable of 
running prescribed check cases or evaluating a simulator run. The output from 
this model consists primarily of cabin temperatures, humidity, and CO 2 partial 
pressure profiles for given starting conditions and dynamic load conditions. The 
air flow into the system is based on the running status and performance charac- 
teristics of the three cabin fans. Flow rates through each of the LIOH canisters 
and the cabin HX are determined in order to calculate the CO 2 and water removal 
rates and heat transfer to the HgO coolant loops or heai. input to the cabin as 
required. 

COg Level 

COg is removed by passing cabin air over LIOH beds contained in a canister. 

The reaction (2 LIOH + COg Lig CO^ + HgO) results in heat production as well as 
vjater which is removed by the subsystem. The efficiency of the LIOH canisters 
in removing COg is a function of bed geometry and on-line time. The cabin CO 2 
level is determined by the time integral of the net of the removal and metabolic 
production rates. 

Cabin Temperature 

Cabin air temperature is determined by calculating the net cabin heat produc- 
tion (or loss) and using appropriate starting conditions and thermal capacitance. 
Heat production sources include metabolic, cabin equipment, LIOH canister operation, 
and wall heating. The heat removal is governed by the cabin temp selector V'/hich 
controls the air flow through the cabin heat exchanger. The cabin heat exchanger 
heat removal rate in turn is a function of the running condition of the H 2 O coolant 
loops and the ATCS. 
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Cabin Huim'dity 

The cabin humidity is determined by calculating the net, cabin water production. 
Water sources include metabolic, food and waste management, LiOH canister operation, 
etc. The removal is a function of the cabin heat exchanger air flow rate, air 
inlet dew point and outlet air temperature. The calculated water removal rate is 
required by the condensate and urine storage model. 

ARS-ACS Validation Methods and Check Cases 

The methods of Sections 5.1 and 4.2 can be used to verify the ARS-ACS 
simulation module. These methods require the use of interface drivers (to provide 
interfacing module functions) and the module functional element drivers to establish 
and maintain desired conditions for each check case. Drivers are required for the 
following: 

0 ARS-ARPCS module 
0 Electrical Power Generation 
0 Electrical Power Distribution 
0 Active Thermal Control module 
0 Food, Water and Waste Management module 

These drivers should provide capabilities for parameter initialization, 
transient response, steady state response, static inputs, and multiple check case . 
execution during a single simulation run. 

The check cases implemented should include step inputs with a comparison of 
the transient and steady-state responses. Initial check cases should also provide 
a thorough exercise of the module internal responses, as outlined in the design 
requirements documents. Latter check cases should implement refinements due to 
actual component and system design/tests. Actual systems/component test conditions 
can be input as a check case with simulation results compared directly to the test 
results. Other check cases should include the maximum, minimum, and nominal load 
conditions for each subsystem. 

ARS-ACS Data Base Impact 

The ARS-ACS reference module and the module drivers previously discussed 
represent a large impact to the simulation data base. Most of the processing 
subroutines (data input/output; data comparison) would be common to all modules being 
validated. Data files are required for input and output data tables. 
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4. 7. 6. 2 Active Thermal Control System 

The Active Thermal Control System (ATCS) provides the positive means of preventing 
orbiter equipment and fluids from exceeding permissible temperature extremes. This 
section describes the current system design, the expected simulation module’s 
functions, identifies parameters associated with the module, and discusses techniques 
of verification of the module performance. 

ATCS Description 

The ATCS transfers heat from “heat sources" to "heat sinks" via a circulating 
fluid and interconnecting valves and tubing. The heat sources include coldplate 
mounted equipment, wanner fluids flowing through heat exchangers, and pumps. The 
heat sinks include fluid evaporators, colder fluids in heat exchangers, and the 
radiator. The heat sources and sinks are connected by controlling valves, tubing 
and fluid accumulators. The Orbiter uses tv/o coolant loops which are identical, 
except that the primary loop has two pumps and accumulators, while the secondary 
loop has only one pump and accumuiator. Figure 4.7-120 (see Refs. 107 and 110) is 
a schematic of the ATCS. A brief description of the major components and their 
pertinent performance characteristics follows. 

Fluid “ The circulating cooling liquid used in the Orbiter ATCS is Freon 21. 

The primary characteristics of interest are the density and specific heat, both 
of v/hich vary with the fluid temperature. The consideration of these temperature 
variations in the simulation is dependent on the required fidelity, 

« 

Pump(s) - The role of the fluid pump is to provide the energy (pressure rise) 
necessary for circulation of the fluid through the loop components. The pump flow 
rate produced v/ill vary with its input voltage and the system's resistance to fluid 
flow (pressure drop). Voltage regulation can be used to reduce the effects of the 
voltage variations. The system resistance (pressure drop) will vary with the 
selection of flow paths. 

Fluid Accumulators - The purpose of the accumulator is to provide adequate 
system fluid volume for thermal expansion, slow leakage, and to provide adequate 
fluid pressure ranges throughout the expected temperature range. The major 
performance characteristics are the fluid volume and the pressure exerted on the 
fluid. The pressure is maintained by a sealed bellows. 
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Heat Exchangers - Heat exchangers provide the means of transfer of heat from 
one fluid to another flov/ing fluid. The major performance characteristic of interest 
is the "overall heat transfer coefficient (U^A)," which varies with the flow rates 
and inlet temperatures of the fluids. A second characteristic is the fluid’s 
pressure drop as functions of the fluid flow rates. These pressure drop character- 
istics are used in determining the total system pressure drop and corresponding 
loop fluid flow rates. 

Evaporators - The H^O evaporator and NH^ Boiler are essentially heat exchangers 
with one of the flowing fluids being allowed to vaporize within the exchanger. The 
energy required for the fluid's vaporization is absorbed from the fluid being 
cooled. This vaporizing fluid is operated "open-cycle" being vented overboard. 

The amount of cooling is dependent on the flow rate and the specific heat of 
vaporization of the fluid being evaporated. The effective heat transfer is there- 
fore dependent on the cooled fluid inlet temperature and flow rate and the quantity 
rate of fluid evaporated. 

The HgO evaporator uses water from the H^O management subsystem as the 
evaporating fluid. The NH^ Boiler uses ammonia from three storage tanks for the 
evaporating fluid. The H^O evaporator is used on-orbit when the payload bay door 
is closed. The Boiler is used after entry, below lOOK feet. 

Coldplates - The coldplates provide heat transfer from the mounted equipment 
to the cooling fluid circulating through the coldplates. The primary performance 
characteristic is the effective thermal conductance. This characteristic varies 
according to the cooling fluid inlet temperature, flow rate and the mounted 
equipment temperature. 

Radiator - The radiator cools the Freon 21 by radiating the heat into space. 

The heat rejection is dependent on the fluid inlet temperature, fluid flow rate, 
surface emissivity, surface absorptivity, and the surface area exposed to sunlight, 
eai'th, and space. 


4.7-3BB 





MDC E1136 
27 January 1975 


Control Logic - The exact switching logic is not currently known. The logic, 
however, represents the control inputs for pump operation, valve positioning, loop 
selection, etc. These inputs can be manual controls, radio frequency commands, or 
automatic equipment comnands. The functions of the logic are normally dependent 
on the voltage level, pressure level, temperatures, etc. 

ATCS Module Functions and Parameters 

The functions provided by the ATCS module include calculations and performance 
determination pertaining to control logic, coldplates, heat exchangers, evaporators, 
radiator, and pumps. Figure 4,7-121 is a block diagram which illustrates the module 
functional elements and interfaces with other modules. Table 4,7-34 provides a 
listing of the parameters associated v/ith the ATCS module. The following paragraphs 
describe the functions performed by each element. 

Control Logic - This element provides logic determination of loop selection, 
pump enabling, valve positioning, etc., allovjing control of the freon fluid flow 
rates, interfaces, temperatures, etc. Inputs would include manual svntch and 
valve positions, radio frequency command, automatic commands, and computer cotrmands. 
Most of these controls are dependent on electrical bus voltage levels to actuate 
relays, valves, or other circuits. The logic would also include the following: 

® Bypass Valve Position controller: a function of the bus voltage(s) 

and HgO evaporator outlet freon temperature, etc. 

Radiator Bypass Valve Position Control: a function of the bus 

voltage(s) and the radiator outlet freon temperature, etc. 

° Radiator Flow Direction Valve Position: a function of the 

payload door position, etc. 

Coldplates - This element provides the calculations of the thermal conditions 
of the col dpi ate mounted equipment and the effect on the coolant fluids. The 
coldplates cooled are the mid-fuselage, aft-fuselage, and OFI coldplates. The 
following calculations should be provided for each coldplate or group of coldplates: 
° Equipment temperatures: functions of equipment mass, equipment 

specific heat, previous temperature, heat dissipation, coldplate 
freon inlet temperature, freon flow rate, freon specific heat, 
heat transfer of the coldplates, heat conduction to walls, etc, 
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TABLE ''L. 7-34. ACTIVE THERMAL CONTROL PARAMETERS 


Parameter 

Type® 

Electrical pov^er bus voltages 

I 

Switches/control selections 

I 

Col dpi ate equipment heat loads or power 


(DPI, AFT fuselage, MID fuselage) 

I 

Heat exchangers (H 2 O payload, Cryo 02 > tuel cell, hydraulics 1/2, 


fluid inlet temps./ specific heats/flow rates 

I 

Heat exchanger U^^A (overall heat transfer conductance) 

I 

Sun angle 

I 

Shuttle attitude 

I 

GSE heat exchanger freon outlet temp. 

I 

H 2 O evaporator, H 2 O inlet temp. /pres sure/flow rate 

I 

Freon pumps on - (primary: 1, 2; secondary) 

P 

Freon system, branch flow rates 

P 

Freon pump outlet pressure, pressure rise 

CP 

Freon accumulator position (quantity) 

P 

Freon temperature (into and out of coldplates, heat exchangers. 


radiator, evaporators) 

CP 

Coldplate equipment temperatures (DFI, AFT & MID fuselage) 

CP 

Heat exchangers - 2nd fluid outlet temperature 


(H 2 O, payload, Cryo O 2 , tuel cell, hydraulics 1/2) 

CP 

Evaporators - evaporation fluid outlet temperature/vapor pressure 


(NH 3 , HgO) 

CP 

1 Specific heats (freon, fluids, equipment) 

p 

\ Controlled valve positions 


j (Diverter, flow proportioning, bypass, radiator bypass, 


1 radiator flow direction, evaporator valves, HgO evaporator 


1 valves, accumulator control valves) 

p 

^ Nfl^ flow rate/quantity remaining/pressure 

CP 

Radiator temperatures 

p 


a 


CP = Critical Performance Parameter 
P ^ Perfonnance Parameter 



n/3C£yomNi::t-L. ASTPiomaLfTscs - sast 


MDC £1136 
27 January 1975 


• Freon outlet temperature; function of equipment temperatures 
heat transfer, inlet freon temperature, inlet freon flow rate, 
specific heat of freon, etc. 

Heat Exchangers - This element provides the interface relationships and 
functions defining the thermal interchange with other modules. This interchange 
includes PRSD, Cryogenic O 2 heating for the ARPCS, fuel cell heat dissipation 
from the power generation circulation system, HgO coolant loop heat transfer for 
the ARS, hydraulic fluid warming for the hydraulics systems, heat transfer from 
payload coolant loops and heat dissipation to the ground cooling loop of the 
prelaunch/launch module. The calculation of the fluid outlet temperatures are 
provided for each interface. 

“ Outlet temperatures: functions of inlet fluid temperatures, 

fluid flow rates, heat conductance of the heat exchanger, and 
fluid specific heats. 

Evaporators - This element provides the calculations associated with the NH^ 
boiler subsystem and control of the HgO evaporator as follows: 

A. NH^ Boiler 

1. Quantity NH^ remaining: function of flow rate, flow time, 

leakage, vent rate, starting quantity for each of three tanks. 

2. Tank pressure: function of quantity remaining, temperature, 

for each of three tanks. 

3. Tank vent flow: function of tank pressure, density. 

4. Evaporator NH^ valve position: function of electrical bus 
voltage, evaporator outlet freon temperature. 

5. evaporator flow rates: function of NH^ tank pressure, 

valve position, and density. 

6. Freon outlet temperature: function of the inlet freon tem- 

perature, freon flow rate, specific heat, NH^ flow rate, 

NH^ inlet temperature, specific heat, NH^ heat of 

vaporization. 
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^ B. H 2 O Evaporator 

1 . H 2 O flow control valve position: function of bus voltage 

level 5 outlet freon temperature . 

2. Outlet freon temperature: a function of H^O flow rate, inlet 

freon temperature, freon flow rate, inlet H 2 O temperature, 
specific heat of fluids, water heat of vaporization. 

Radiator - This element determines thermal results and conditions for heat 
rejection. 

® Radiator temperatures: function of the Inlet freon temperature, 

freon flow rate, heat rejection, mass, specific heat, freon flow 
direction (payload door position), 

® Radiator heat rejection: a function of the radiator temperature, 

vehicle attitude, vehicle state vector, beta angle, payload door 
position, freon flow direction, 

® Radiator outlet freon temperature: a function of freon flow rate, 

j inlet freon temperature, heat rejection, freon flow direction, 

radiator bypass valve position, specific heat, etc. 

Freon FI ow/Pressure/Temperatures - This element determines the freon system/ 
branch flow rates, pressures, and integrated temperatures. 

® System/Brancb flow rates: functions of the system configuration, 

pump selection/enabling, freon temperatures , pump and equipment 
flow/pressure characteristics, bus voltage level. 

° System pressures: functions of the flov/ rates, temperatures, 

accumulator quantities, flovz/pressure characteristics , system con- 
figuration, bus voltage level. 

® Integrated freon temperatures: function of mixing freon flow 

rates/temperatures , system configuration. 

Accumulator freon quantity: function of the freon leakage, flow 

rate, temperature. 
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ATCS Reference Data Sources and Formats 

ATCS System and component design performance requirements, analysis, 
predictions, and tests provide data for direct comparison with the Shuttle 
simulation results. Figure 4.7-1 22 is an overview flow chart of a method of 
reference source selection and comparison. Reference 22 {updated at intervals) 
is a source of component and systems performance data regarding design requirements 
analysis, tests, and actual flight. Design requirements are available from 
Reference 108. The analysis and test results should be available from Shuttle 
design and evaluation groups. 

In addition, several computer programs are available which can be used to 
develop suitable reference modules or to use in performing analysis of the system. 
References 12 and 102 provide descriptions of system component subroutines which 
can be combined to provide a reference module for the ATCS. The G189A program of 
Reference 12 was developed for JSC and is a versatile analytical tool for support 
of environmental systems work. Reference 105 describes an ARS/ATCS performarce 
subroutine designed for use with the Wang 700 series programmable calculator. This 
subroutine allows an average run time of five minutes per case as opposed to hours 
or days turnaround when using the regular computer facilities. Figure 4.7-123 
provides a overview flow chart of an ATCS reference module. 

ATCS Validation Methods and Check Cases 

The ATCS module can be verified by the techniques described in Sections 4.2 
and 5.1. During the verification the following drivers are required to provide the 
necessary range of inputs and conditions for establishing each checkpoint. 

& Electrical Power Generation 
0 PRS and D 
0 ARPCS 
0 ARS 

0 Payload thermal control loop 
0 Prelaunch/launch GSE cooling 
0 Hydraulic subsystem heating 
0 Food, H 2 O, waste management 
0 Equations of motion 
0 Intra module functional elements 
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LEGEND : 

Atf ~ Effective flow area of control valves 
Evaporator fluid quantity 
Pump freon flow rate 
-OTg- Freon loop branch flow rate 

- Heat exchanger Interfaces circuit flow rate 
Evaporator fluid flow rate 
Freon flow rate through radiator 
r^-Sun rays incidence angle with radiator panel 
Earth view angle with radiator panels 

Freon average temperature 
Branch freon temperature 

exchanger freon outlet temperature 
■^Lo^-Heat exchanger interface circuit outlet temperature 
Heat exchanger freon inlet temperature 
Tr-rf/- Heat exchanger Interface circuit inlet temperature 
Evaporator outlet freon te’nperature 
Evaporator fluid tank temperature 
Evaporator outlet evaporation fluid temperature 
Tp.,^s~ Evaporator freon inlet temperature 

Evaporator inlet evaporation fluid temperature 
Radiator inlet freon temperature 
'fp-off- Radiator outlet freon temperature 
7^s “ Temperature of radiator surface 

preon loop pressure drop 
Freon loop effective length 
Effective branch length 
Freon loop flow diameter 
Branch flow diameter 
Freon viscosity 

Freon loop effective roughness 

7r “ Evaporator storage tank pressure 
? “ Evaporator pressure on evaporation fluid circuit 
Ambient pressure 
FIGURE 4.7-123 (CONTINUED) 
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The system design requirements (see Ref. 108) provide component and system 
maximum/minimum acceptable performance levels. These requirements should provide 
the initial check case conditions. The results of various contractor- and NASA- 
performed analysis, studies, and evaluations can provide higher fidelity verification 
check cases. Later, data from actual systems and component tests as v/ell as actual 
flight performance can be used to establish the more severe verification check cases 
for both the module and the individual functional elements. 

The' check cases should include the exercise of each individual functional 
element and of the module functioning as a unit. The approach for individual 
functional element verification is to nullify or isolate all interaction with other 
elements and allow the calculation of selected outputs for controlled input 
parameters. 

ATCS Data Base Impact 

The ATCS reference module and the ATCS nodule drivers as previously discussed 
will have a large impact on the simulator data base. The processing subroutines 
(such as data input/output and data comparison) are of small impact, and most of 
them will be common to all the modules being validated. 

4, 7. 6. 3 Food, Water and Waste Management (FWV/M) 

This system provides control, storage and utilization of food, v/ater and 
waste. The simplified schematic of the water subsystem (from Ref. llo) is shown 
in Figure 4.7-124 . Figure 4.7-1 2f) is a schematic of the waste management subsystem 
(also from Ref. no). 


FWWM System Description 

Food Management - This subsystem provides for the storage and preparation of 
crew meals. 

Water Management - The water management subsystem provides for the collection 
of fuel cell product water, storage in the three potable water bottles, and 
subsequent delivery to water sublimators, overboard dumps, airlock, and food 
management subsystem. 

Waste Management - This subsystem provides for the collection, storage, and 
disposal of condensate (from the ARS subsystem) and human waste. 
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FWVJM Module Functions and Parameters 

The food management system is a lower-deck function, and thus will not be 
dynamically simulated. The waste management system only requires the condensate 
collection (flow rate) to be dynamically simulated. The water management sub- 
system, however, interfaces dynamically with the fuel cell and ARS-water coolant 
loop (water sub lima tors). The module performance parameters are identified in 
Table ^7-35. 

Water Management - This functional element provides the following calculations, 

0 Water flow rates to using outlets - functions of the tank pressures, 
outlet pressures, and effective flow areas. 

0 Tank H 2 O quantities - functions of initial quantity, flow rates, and time. 

Waste Management - This functional element provides the calculation of the conden- 
sate flow rate from the condensing heat exchanger to the urine storage tank or 
vacuum dump. The flow rate is a function of the heat e>xhangers inlet pressure, 
condensate quantity and tank pressure. 

FViWM Reference Data Sources and Formats 

FWWM subsystem design requirements, analysis, and test results can be used 
for module verification. In addition, certain math models described in previous 
portions of Section 4.7,6 can be utilized for this module. Figure 4.7-126 to 
calculate the liquid flow rates, can be developed into a suitable reference module. 
Those portions that are not dynamically simulated can be functionally provided by 
a performance profile (i.e., a tabular function of time). .Reference 22 , 109, and 
23 are sources of component and subsystem performance requirements and data, 

FWWM Validation Methods and Check Cases 

This module can be verified by the techniques described in Section 4.2 and 
5.1. Module drivers are required to provide the fuel cell inlet water flow rates, 
water sublimator pressure, water tank pressure/temperature, and condensing heat 
exchanger inlet pressure. Check cases can be developed utilizing component and 
systems maximum and minimum performance design requirements, analyses, and system 
evaluati ons. 
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TABLE ^.7-35 FOOD, WATER AND WASTE MANAGEMENT PARAMETERS 


PARAMETER 

TYPE® 

Condensate heat exchanger H 2 O quantity/pressure 

I 

Ambient pressure 

I 

Fuel cell water flow rates/temperatures 

I 

Water chiller and heater flow rates 

I 

Water sublimator pressure 

I 

Water container pressure/temperature 

I 

Water sublimator pressure regulator flow areas 

P 

Water container water quantities 

CP 

Fan/Separator flow rates 

P 

Urine tank quantities/pressures 

P 


3p = Performance Parameter 
CP = Critical Performance Parameter 
I = Input Parameter 
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LE6EMD: 

fay - Pressure of J— load 
Manifold pressure 

' Source pressure of I — tank 

t h 

Source temperature of I — tank fluid 

"th 

Liquid flow rate from I — tank into manifold 

iili 

Liquid flov/ rate from manifold to J — load 

— th 

Liquid temperature into manifold from I— tank 

th 

TSLy- Fluid temperature delivered to J~ load 
Fluid velocity from I— tank into manifold 

■J*Vi 

Fluid velocity from manifold to J~ load 
77i - Fluid temperature in manifold 
/l- Fluid density 

Fluid mass in manifold 
-niM-r I~ tank fluid quantity 
c. - Fluid specific heat 
AtL - Time increment 

^se* " Flow area from I~ tank into manifold 

ji t 

njD- Flow area from manifold to J — load 
V^^^-Volume of fluid in I— tank 



FIGURE 4.7-126 (CONTINUED) 
4.7-407 
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FWWM Data Base Impact 

Impact to the simulation data base is small. The reference module should be 
relatively simple. Few drivers are required, and the comparison/processing 
subroutines would be common to other simulation modules. 
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4.8 MODULE INTEGRATION 

The size and complexity of the simulators we are concerned with in this study 
militates against the use of either a pure “top-down" or "bottom-up" integration 
sequence. We anticipate that simulation integration will proceed, instead, by a 
process of "agglomeration." That is, validated modules which have a high degree 
of interaction will be integrated into distinct "clusters." When these individual 
clusters have been validated, they will be integrated with each other, again on 
the basis of their degree of interaction, until the complete simulation has been 
integrated. 

V 

Validation aspects of the clustering process are discussed in Section 5.2. 
This section is concerned only with the definition of a probable integration 
sequence for a large spacecraft simulator. The basic information used to develop 
this sequence is taken from our module interface diagrams: Figures 4.3-2, 4, 6, 

7; 4.4-2, 3; 4.5-2, 4, 5; 4.6-1; and 4.7-11, 28, 42, 67, 70, 84, 94, 116, 135, 

162, 174, 187, 202, 222, 234, 242, 252, 276, 285, 299, 306, 326, 375, and 390. 

Figure 4.8-1 depicts an integration sequence developed on the basis of this 
Information. No "drivers" are shown explicitly on this figure, the assumption 
being that whatever drivers are necessary for the modules in question will be 
provided. VJherever possible, the actual simulation executive should be used as 
the basic driver, with additional drivers or "stub" subroutines used to 
substitute for modules not yet • integrated. 

Major stages in the integration process are separately identified as named 
clusters in the line of integration flow. In several cases, a "replica" of a 
module or cluster (e.g., the ECL5 and the Trajectory Cluster) is shown in use 
on more than one line of flow. When these distinct lines are merged, excess 
replicas will of course be removed. In open-loop applications, previously-written 
tapes may be used in place of an on-line replica of the required module/cluster. 

In addition to the natural sequence of integration derived on the basis 
of hardware/software interactions, the timing of the process will be constrained 
by the availability of modules; this is particularly true of hardware. The 
flight computer/flight hardware interface device (FC/FHID), for example, may 
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profitably be integrated anywhere between the "earliest" and "latest" positions 
shown on the figure. If the FC/FEID is unavailable when desired, its functions 
must also be provided by a driver of some sort (a functional simulation or 
emulation). Of course, the most efficient overall development will result if 
hardware and software development is scheduled to provide modules in a sequence 
which is compatible with the natural integration sequence. 
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4.9 SPECIAL TEST REQUIREMENTS 

Spacecraft hardware tests are conducted for both static and dynamic test 
conditions, at the component level, integrated subsystem/system level, and the 
total vehicle level. In these respects, the hardware test sequence seems to 
resemble the simulation validation sequence as we know it. This would lead us to 
expect test data to be an Important category of reference data for simulation 
validation. 

f 

However, it is Important to remember that the goal of hardware testing Is 
to prove out the hardware, not to support simulation programs. Thus, certain 
characteristics of test programs and normally-available test data tend to reduce 
their utility for simulation validation. This section first discusses the general 
characteristics of various test programs and of the resulting data, based upon 
experience from past space programs. It then suggests potential changes in test 
operations, data-gathering and data-handling which would enhance the usefulness 
of test data for simulation validation. Finally, some consideration is given to 
the question of how simulation project personnel might interface with test groups 
to affect implementation of the desired changes. (This topic, however, is not 
strictly within the scope of this study.) 

Suggestions for the use of test data to validate individual simulation 
modules will be found in various module-oriented sections {e.g., 4.5,2, 4.7.1 .4). 

4.9.1 Survey of Conventional Test Operations 

There are three basic classes of testing performed during the development of 
a space vehicle: :omponent tests, system tests, and vehicle tests. In this 

section, we discuss various characteristics of these tests -- purpose, time frame, 
types of data taken, documentation, and potential problems in using the test data 
for simulation validation. Example data are shown. 

4. 9. 1.1 Component-Level Tests 

We expect component-level tests to be the most fruitful In terms of providing 
directly-usable reference data. Component tests will fit the simulator development 
cycle best, and provide data which is more performance-oriented than the other 
classes of test. 


4.9-1 


fVTCDO/V/VE‘1.*. S30UG1-AS - EAST 


MDC Ell 36 
2? January 1975 


Development and Bench Tests 

These tests are intended to verify hardware design concepts, establish design 
parameters, predict flight hardware perfomance, and identify the potential 
influence of such environmental factors as temperature, voltage level, acceleration, 

etCr 


Test Characteristics — These tests, conducted with early prototype hardware, occur 
rather early in the hardware design phase. For many onboard systems, this time 
period vdll coincide with the simulation software development phase. Tests are 
often quite rigorous with regard to the range of environmental conditions and 
input forcing functions. Extensive engineering analysis is often performed upon 
the resulting data, including updating of the contractor's local analysis/simulation 
programs to reflect the performance parameters as estimated from test data. 

Typical Documeatation -- Both informal and formal test documentation may be 
generated. The informal documentation (recorded during the actual conduct of the 
test) may consist solely of hand-entered parameter and environmental values, with 
various annotations. In modern test laboratories, however, it is becoming common 
to record test data automatically, using on-line minicomputers. The data format, 
hov/ever, will be highly customized, and probably rather abbreviated, whether in 
hard copy, punched tape, or magnetic tape. 

The formal documentation will be free-form test reports, reproducing the 
more significant portions of the test data (raw and/or reduced), and providing 
some engineering analysis of the significance of the results in terms of the 
performance of the component. 

Potential Problems — The formal test documentation is not often widely distributed; 
simulation personnel must often make personal contact with cognizant engineers to 
even become aware of the existence of such documentation. The informal documentation, 
obscurely formatted, often cannot be used without the aid of the people who v;ere 
actually involved in the generation and/or reduction of the data. Even the formal 
documentation will often require further analysis to be put into a form useful 
for module validation. Finally, the performance data may be obsolete, due to 
design changes based upon the test results; indeed, this is the basic reason for 
conducting such tests. 
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Example — Figure 4.9-1 resulted from the evaluation of development test data for 
^ certain Skylab I electrical -equipment coldplate heat transfer coefficients; see 
Ref. 14 . 

Qualification Tests 

"Qua! tests" are performed to verify that components operate within 
specification limits, during and/or following exposure to specified environmental 
extremes, such as shock, vibration, temperature, and overvoltage. Life tests also 
fall in this category. 

V * 

Test Characteristics — These tests are started early in the component's 
production history, and are continued through the component production phase, often 
on a 100?i testing basis. Very little parametric data is collected from qualification 
tests, which are intended only to provide go/no-go information at specification 

I 

limits. 

Typical Documentation -- Qualification test results, considered highly significant 
to the success of the hardware program, are quite formally and thoroughly 
documented. The reports are widely distributed and widely evaluated. 

Potential Problems -- The test data is not parametric in nature, and is almost 
always at extremes of environmental conditions, providing little or no information 
about performance under nominal conditions. 

Acceptance Tests 

Acceptance tests are conducted on individual production units, prior to 
installation in the flight vehicle, to verify that each unit has been properly 
assembled, and performs within specification over a reasonable range of operating 
parameters. 

Test Characteristics — These tests are conducted with production hardware slated 
for installation in actual flight vehicles. Accurate, parametric performance data 
reflecting normal operational conditions is recorded for each individual unit, and 
tagged with the serial number for the production unit. Since data is available for 
multiple units, it becomes possible to determine the inherent scatter in the 
performance-parameter data, which helps to establish fidelity criteria for 
simulation validation. n o 
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FLOW PER UNIT COLDPLATE WIDTH (LB/HR/IN.) 


FIGURE 4.9-1 . COLDPLATE HEAT TRANSFER CHARACTERISTICS 
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Typical Documentation — Rather thorough, formal documentation is prepared for 
each serial -numbered component. The tests results, however, normally remain with 
the unit until installation, and do not receive wide distribution. 

Potential Problems — Acceptance-test data does not become available in time for 
initial simulation validation, although it can serve as a good reference for 
simulation updating. The data must generally be "filtered” and reformatted to be 
directly useful for valida^tion. Test documentation normally remains with the 
tested unit, and is not widely distributed, posing something* of a retrieval problem. 

Examples -- Figure 4.9-2 , from Ref. 14, shows typical acceptance-test data from 
an individual component (a pump for a Skylab coolant loop). Also see Figure 4,2-10 
‘of Section 4. 2. 1.4, which shov/s operational envelope data, compiled from a number 
of individual acceptance-test results on Individual pumps, which were retrieved via 
considerable "legwork." 

4. 9. 1.2 Systems-Level Tests 

Systems- level tests are conducted after components have been integrated into 
subsystems and systems and, in some cases, installed on the space vehicle. They 
normally require rather complex setup and operational procedures, which must be 
faithfully duplicated for th® results to be meaningful. 

Systems Development Tests 

These tests verify system conceptual designs, and lend confidence to the 
results of prior analyses and simulations. 

Test Characteristics — The tests are performed late in the design phase. 

Complete or partially integrated subsystems are operated with simulated external 
inputs, loads, etc. Data may be taken at isolated performance points, or may be 
parametric over an operational range of interest. The type and amount of data 
taken will depend upon the (formal or informal) test plan, the degree 
of prior confidence held by the investigators, and upon whether initial results 
turn out as expected. Unexpected results will usually induce the investigators 
to take more data, and to exercise the system over a wider range, in the interest 
of later analysis. 
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Typical Documentation — Semi-formal documentation is normally prepared, consisting 
of a brief cover report of problems, conclusions, etc*, followed by a description 
of the test procedure and reproduction of the test data sheets as recorded during 
the test. Generally, the only information which becomes widely known is the 
problems encountered. 

Potential Problems -- Data becomes available rather late for simulation use. The 
systems as tested may lack certain components, and test conditions may be 
unrealistic and/or hard to duplicate in a simulation. T-he data may be incomplete 
and in an inconvenient format. 

Example -- APU spin-up tests (rotation vs. time); APU fuel consumption under 
various hydraulic loads. 

Integrated Systems Test 

This is a go/no-go test series for the integrated vehicle, to verify that 
the performance of the various interacting systems is correct (within the acceptable 
range of values). 

Test Characteristics — With multiple systems installed in the vehicle, energized 
and operated according to a rather precise and complex procedure, isolated 
performance data points are taken over a range of conditions. Since the test is 
of a go/no-go nature, the actual parameter values are often not recorded if they 
fall within the expected range. 

Typical Documentation -- The test report will include a description of the test 
procedure or "script," and indicate v/hether the data taken fell within the 
expected range; few actual performance parameter values are provided. 

Potential Problems — Integrated systems tests occur during the vehicle integration 
phase, late relative to simulator requirements. Little useful data is provided in 
the test results, and what useful data is available is difficult and time-consuming 
to extract. The test setup is difficult to duplicate on the simulator, even if the 
published script is followed exactly. 
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Example — Figure 4.9-3 was excerpted from a ten-page test procedure published 
in Ref, 113. 

Vehicle Prelaunch Checkout 

These tests are conducted to verify operability of each vehicle prior to 
launch. 

Test Characteristics These tests require highly complex procedures, which are 
often fully or partially automated using a variety of computer systems. Isolated 
performance data points are taken, and tested against acceptable ranges; actual 
parameter values are often not recorded. 

Typical Documentation — N!uch of the data remains within the checkout complex in 
volatile form, and is never published. Summary reports usually only cover 
anomalies observed, and are not widely distributed. 

Potential Problems -- Very little useful data can be expected from prelaunch 
checkout. Tests occur very late for simulation purposes. 

4. 9. 1.3 Vehicle Flight Tests 

Flight tests are conducted to verify the operational readiness of the 
complete vehicle and its onboard systems in its. actual environment. Successful 
flight tests develop confidence in in-space capabilities, procedures, etc. 

Test Characteristics -- Flight tests provide data which reflect the actual 
operational environment of the vehicle. Great quantities of data are recorded -- 
both external (ground tracking) and onboard- system performance parameters 
(telemetry stream and onboard recording). The data stream includes both 
discretes, such as switch settings and event markers, and continuous parameters, 
such as accelerations, temperatures, voltages, etc. Rather complex commutation 
and framing schemes are necessary to record such a quantity of data. For 
example, the onboard data acquisition system used during DC-10 flight tests is 
described by Ref. 112 as follows: 

“Most data recorded in the airborne system are digital, 
although it also has a secondary FM-FM recording capability. The 
400 telemetry channels are divided into 90 recording at prime 
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SEQUENCE 

SYSTEM 

AREA 

DESCRIPTION 

remarks 

02-031 

EMC 

PHOTOGRAPH VOLTAGE SPECTRUM (FREQUENCY DOMAIN, 1 KHZ 
TO 110 t-GlZ) OF EXTERI;aL power (POSITIVE LEAD ON PIN G, 
NEGATIVE LEAD ON PIN U) . 




CAUTION 



i 

ALWAYS USE XIO ATTENUATOR PROBE IfdEN USING- FET PROBE TO 
AVOID TEST EQUIPMENT DAMAGE. 


02-032 

EMC 

1 

1 

V 

OPEN SWITCH SI ON BREAKOUT BOX (EXT PWR IN). 
PHOTOGRAPH CURRENT SPECTRUM (FREQUEi;CY DOMAIN, 1 KHZ 
TO 110 MHZ)'. CLOSE SWITCH. 


02-033 

EMC 

OPEN SWITCH SI 2 ON BREAKOUT BOX (EXT PWR RET). 
PHOTOGRjYPH current spectrum (FREQUENCY DOMIN, 1 KHZ 
TO 110 MHZ). CLOSE SWITCH. 


02-034 

EMC 

RECORD MEMORY VOLTl'IETER READINGS AND RESET THE METERS 




NORM VOLTS 

10 S VOLTS 


02-035 

LGP 

HOVE AUXILIARY FIRING SWITCH S9 TO STANDBY Al^D HOLD 
AGAINST DETENT SPRING. 


02-036 

HARCO 

PLACE OPERATION POWER SWITCH TO NORMAL. 


02-037 

LCP 

VERIFY LCCP STANDBY WINDOW AND READY TO FIRE WINDOW 
ILLUMINATED, 

j 




STANDBY CHECK 1 

READY TO FIRE CHECK 

1 


02-033 

MRCO 

1 

VERIFY: ' 

IGNITER EXTENDED-OFF CHECK 

OPEFJVTION POWER- ILLUMINATED CHECK 


02-039 

. EMC 

RECORD MEMORY VOLTMI^’ER RFJlDINGS AND RESET THE METERS 



i 

NORM VOLTS 

10 S VOLTS 



FIGURE 4.9-3 . EXCERPT FROM AN INTEGRATED-SYSTEM TEST "SCRIPT." 
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sampling rates, 290 recording at a 10:1 subcommutation rate, and 
20 recording at a 20:1 subcommutation rate. The prime channel 
sampling rate can be changed in flight from 400 to 10 samples per 
second in six stages. 

"The up-to-2400 parameters on one aircraft are transmitted 
over the 400 channels by onboard multiplexing of some data. Data 
from 64 temperature sensors on an engine may be multiplexed on 
board into one channel, for example." 

y • 

Typical Documentation — Qualitative and semi quantitative data is provided by 
crew debriefing reports, flight control reports, and final summary reports. The 
informal reports become available soon after the flight, while the formal summary 
reports may not be published until months later. 

The bulk of the quantitative data remains available on magnetic tapes. 
Depending upon the software, hardware and retrieval aids provided, it may be a 
fairly simple matter to obtain tabulations and plots of any desired parameter 
time-histories from a particular flight — or it may be extremely difficult. 

Where the inputs and outputs for an onboard system can both be obtained as 
functions of time, the validator will have a directly-usable, highly realistic 
check case for simulation validation. 

Potential Problems — Flight test data becomes available too late for initial 
simulation development and validation, but should be useful for subsequent 
updating. The available check cases are constrained by the actual mission 
timeline, and may require complex setup to duplicate the operational conditions 
on the simulator. It may be difficult to obtain sufficient data to accurately 
define the environmental conditions in which the vehicle was operating. Potential 
availability of the data is sharply dependent upon the power of the retrieval 
and data-reduction aids provided by the spacecraft project. 

4. 9, 1.4 Shuttle-Related Test Documents 

Table 4.9-1 provides a list of currently-published documents relating to 
planned tests for the Shuttle program. 
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TABLE 4.9-1 , POTENTIALLY USEFUL TEST DOCUMENTATION 


MJ072-0004-3 

Shuttle Master Verification Plan, 
Volume 3: Orbiter Verification Plan 

ML0101-0001 

Test Requirements: In-Process and Acceptance-Orbiter 

SD72-SH-0009 

Orbiter Quality Assurance Plan 

SD72-5H-0112-6-II 

RDD-Major Ground Test-Thermal Vacuum Test Program: 
CMS-RC5 POD 

SD72-SH-0112-12 

RDD-S:’bsystem Ground Test-Docking Mechanism Dynamic Simulation 

SD-72-SH-0112-13 

RDD-Ground Subsystem Test-Orbi ter/External Tank Separation 
Subsystem Test 

SD72-SH-0112-18 

RDD-Subsystem Ground Test-APU Integration Test 

SD72-SH-0112-19 

RDD-Subsystem Ground Test-ECLSS Test Article 

SD72-SH-01 12-21 

RDO-Subsystem Ground Test-Escape System Test Article 

SD73-SH-0062 

Checkout Plan: Orbiter and Combined Elements Ground 

Operations 

S073-SH-0094 

Manual, Technical and Mon-De:tructive Testing, Space Shuttle 
Specification for Preparation of 

SD73-SH-0298 

SD74-SH-0011 

through 

Avionics Development Laboratory General Test Plan 

SD74-SH-0049 

Subsystem Certification Plans 
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4.9.2 Idealized Test Programs 

Based upon an understanding of historical norms in test operations, we are now 
in a position to consider what changes would be desirable to make test data a more 
valuable source of reference data for simulation validation. Efforts should be 
concentrated upon component-level tests, for at least two reasons: 

(a) Component-level tests appear to be an inherently more valuable source 
of reference data. 

(b) System-level and vehicle-level tests are already so complex and expensive 
that resistance will likely be encountered to any changes which would 

V 

make them still more complex and expensive. We recommend a three-step 
approach to maximizing test-data utility: (!) identify required data, 

(2) develop an idealized test plan, and (3) define the data recording 
and documentation desired. 

4, 9. 2.1 Identify Required Data 

In the analysis of spacecraft subsystems and associated simulation modules 
provided in Section 4.7, we have identified inputs, performance parameters and 
critical performance parameters for each module. Obviously, the data most desired 
from a test are the values of the component inputs and the critical performance 
parameters. Fortunately, these will in most cases also be the data most desired 
from the test by the !.jv’dv/are designers. For high-fidelity simulation, non- 
critical performance parameters will also be desired, but at lower priority, thus 
giving the test designers a “shopping list" against which they can evaluate 
potential time and cost impacts of setting up increased test instrumentation and 
recording capability. 

The workload of establishing data requirements for each onboard component 
will be minimized by unifying the analysis of similar components, regardless 
of their end use. The guiding philosophy would be that, for example, "a pump 
is a pump is a pump," whether it is a fuel pump in the main propulsion system, 
a coolant pump in the ECLS, or a lubricant pump for the APU. The parameters of 
interest - RPM, differential pressure, flow rate, etc, -- would then be the same 
for all pumps on the vehicle. 
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4. 9. 2. 2 Develop an Idealized Test Plan 

The ideal test for a component is one which would translate directly into a 
check case for validation of the associated simulation module. The analysis steps 
necessary to define such a test are as follov/s: 

(a) From preliminary analysis or simulation results, determine the 
expected range of the component inputs and performance parameters. 

(b) From similar performance predictions, define the expected shape of the 
performance curve between its upper and lower limits. 

V 

(c) Determine the minimum number of input values necessary to define this 
performance curve, and the best choice of values based upon the curve 
shape- This will commonly lead to non-uniform spacing of checkpoint 
values — widely spaced in regions of expected uniform slope, closely 
spaced in regions of expected high curvature. 

Similar considerations will apply for defining the time-spacing of data- 
points for dynamic response of a component, based upon the estimated transfer 
function of the component and the expected bandwidth of input forcing functions. 
Standard test descriptions would be prepared for basically-similar components, 
such as pumps, as discussed above. Performance curves for all such similar 
components would be expected to be similar in shape. 

4. 9. 2. 3 Define Desired Data Recording and Documentation 

During the conduct of the actual test, the data to be recorded will consist 
of environmental conditions, input stimuli, and output responses of the component/ 
system. These should, of course, be actual values, rather than go/no-go 
assessments. Accuracy, time spacing, and other data attributes v/ill generally 
be selected by the test personnel on the basis of available instrumentation and 
the requirements and goals of the test. Accuracy estimates will be helpful in 
making proper use of the test data. 

The normal recording format and medium will be hard-copy tabulations, 
either handwritten or minicomputer printout. Where available, graphical data will 
be very desirable. Magnetic tape records v/ill probably not be available, and are 
likely to be incompatible in format with the simulation computer in any event. 
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Test documentation should include units, scale factors, known biases, and 
any other adjustments necessary to use the data as a simulation check case. 

4.9.3 Implementation of Test Enhancements 

Although simulation personnel should make every reasonable effort to 
communicate their requirements to test personnel, it must be assumed that the 
goals and economic constraints of the hardware programs will take precedence. 

Thus, the simulation/validation test- interface group should become familiar 
enough with test operations, requirements and instrumentation to assess the 
potential impact of whatever enhancements they plan to request. 

This will require the early establishment and continuing maintenance of 
effective liaison with design and testing groups, to accomplish the follovnng: 

© Communicate their needs for performance-oriented data from component/ 
system testing. 

© Make test personnel aware jf the data formats and documentation which 
v^ould make test data most useful for simulation validation. 

© Ensure that they will receive available test data in a timely manner. 

0 Evaluate the probable impact of unexpected test results upon hardware 
designs, operational procedures, etc. 

In some large test organizations (e.g., the DC- 10 flight test organization), 
a formal structure for integration of various user's requirements into test design 
will already be in existence; the simulation personnel will need only to make use 
of the existing interfaces. (It is to be expected that PICRS will provide 
assistance in this area.) Where formal lines of communication do not yet exist, 
the simulation program vnll need to make efforts to establish new working 
interfaces, to make their requirements known. Ideally, the personnel assigned 
to this liaison function would have extensive experience both in simulation 
development and hardvjare design and testing. Where such personnel are initially 
unavailable, some cross-training will be required. 
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4.10 REFERENCE DATA FORMATS 

This section discusses rnethods for formatting of reference and simulation 
data, to obtain the fol levying benefits: 

0 Maintain 'Compatibility betvfeen reference module and simulation module 
inputs ami outputs. 

0 Optimize verification data-handling, comparison and evaluation pro- 
cesses-^ manual and automatic, 

t 

V . 

0 Minimize simulator verification data base impact. 

4.10.1 Tteference Data Types 

Reference data to be used as standards of performance for simulation 
validation may be available in either machine-readable or non-machine-readable 
form. 

4.10.1.1 Mon-Machine- Readable Reference Data 

Non-machine-readable reference data — numerical tabulations and plots — 
vnll become available to the validation staff from several sources: 

0 System and subsystem data books, which compile data derived from per- 
formance predictions, analysis/simulation programs, and component/ system 
tests. 

0 Component, subsystem and system tests, providing raw data taken during 
test execution, and/or reduced data published in test reports {see 
Sect. 4.9). 

0 Printout and/or plots from existing analysis/simulation programs not 
under the control of the validation staff. 

4.10.1.2 Machine- Readable Reference Data 

Machine-readable reference data may be provided by any of the following 
means : 

0 Standard plot tapes generated by multi-user anc lysis/simulation programs, 
such as SVOS (see Sect. 4. 2. 1.3). 
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0 Output data files (tape or disk) generated by either an existing analysis/ 
simulation program operated under control of the validation staff, or a 
new reference module developed specifically for validation purposes. 

(This includes highly-detailed reference trajectory tapes.) 

0 Basic data tapes provided by an outside cpntractor-.gr apency (e. g. , 
planetary ephemeris tapes, vehicle aerodynamic’ data tapes). 

V * 

4.10.2 Reference Data Generation, Handling and Conversion 

Clearly, radically different methods are required for the handling of machine- 
readable and non-machine-readable data. For non-machine-readable data, we have 
the options of either performing the comparison/evaluation in a purely manual 
mode, or hand-entering the data into the computer for automated comparison/ 
evaluation. For machine-readable data, we may either put the data out for 
manual comparison/evaluation, or perform automated comparison/evaluation within 
the computer (see also Sect. 5.5). 

4.10.2.1 Handling of Non-flachine-Readable Data 

We recommend that when the reference data is in non-machine-readable form, 
the comparison and evaluation required for simulation validation be performed in 
a purely manual mode. To simplify the manual operations, reduce v/orkload and 
fatigue, and eliminate all possible sources of error or misjudgement, it is 
essential that the simulation data be mapped into a format v/hicb is as nearly 
identical as possible with the pre-existing format of the reference data. 

Formatting factors involved in tabular data include headers, physical 
arrangement of data on the page, spacing of independent-variable values, and 
units, axes, and numerical format of individual numerical entries. 

Graphical output from •.'iniulation module drivers should be designed to enable 
the simulation-data plot to be exactly overlaid on the reference-data plot, for 
convenient "eyeball" evaluation of fidelity. The factors which must be controlled 
to enable such overlaying include axis conventions and units of the basic data, 
as v;el1 as axis lengths, origins and scale factors of the plot itself. Since 
plots found in data books and other sources may not be reproduced in their 
original full size, highly flexible formatting and scaling capabilities will be 
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required for the simulation data-handling support software. 

Since great flexibility is desired for the required data-handling support soft- 
v;are, consideration should be given to "human engineering" factors in the design 
of this software -- i.e.* command vocabulary and formats j control of options, 
free-form input, etc. The goals of the support-softv/are design should be to 
provide all required formatting capability, achieve a practical minimum of 
workload in obtaining the required hard-copy, and minimize the potential for 
errors induced by the support softivare itself. 

y 

Hand-entry conversion of non-machine-readable data into machine-readable 
form is definitely not recommended. The labor and error potential of the re- 
quired manual operations, in our viev/, more than offset the potential gains of 
automating the comparison and evaluation. 

4.10.2,2. Handl'-g of Machine-Readable Data 

'when both the reference and simulation data are in machine-readable form, 
the basic processing for comparison and evaluation is rather simple (see Sect. 5.5). 
The bulk of the progranaaing effort and computer time is likely to be expended in 
pure data-handling; file searching and retrieval, record searching and re- 
trieval, data formatting and adjustment, etc. For that reason, we believe that 
substantial benefits can be realized from the early establishment, continuing 
maintenance, and broadest possible application of a universal data format . 

Formats for Hew Validation Software 

This universal format would encompass axis conventions and units, decimal 
formatting of discretes, fixed-point and floating-point data, data sampling rates 
and the mapping of softv/are input and output data streams into time-tagged 
"pages" or "frames" of data. The basic properties of such a universal data format 
are illustrated in Fig, 4.10-1. (Also see Sect. 4. 9. 1.3 for a brief description 
of the framing scheme used for onboard rec': rding and telemetry of DC-10 flight 
test data.) The formatting and framing information necessary to utilize the data 
would automatically be recorded on a "header" preceding each data file. 

VHth the amount of study and development which has already gone into the next 
generation of training and proceduros-dcvelopment simulators for HASA-OSC, it 
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ITEH ^ 
1 
2 
3 

4-5 


5 

6 

7 

8 
9 

10 

n 

12 

13 

14 


DESCRIPTION 

Data file Identification (fixed-length alphanumeric title) 

Date file was generated 

Type of data: reference, simulation, both 

Identification of reference and simulation modules used 
to generate data 

Data word length 

K=Mumber of v/ords per data frame 

Nominal frame rate (frames per second) 

M=Total number of frames (if known) 

N=Total number of parameters in this file 

Identification name or code for first parameter 

Location of parameter srl in each frame in which it 
appears 

Word length for paranieter #1 (several short parameters 
may be “packed" into a single v/ord) 

Frame frequency for parameter #1 

(Same information for parameters 2 through N) 


4N -J- 9 

(a) Header Block 

FIGURE 4,10-1. SCHEMATIC OF A UNIVERSAL FORMAT FOR VALIDATION DATA FILES 
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FRAME # WORD § 

1 1 
2-K 


DESCRIPTION 
= Frame Time 

Paranieter values at time t-j 


2 


1 


t 


2 


2-K 


Parameter values at time t 2 




f'-H-l 


1 


t 


m 


2-K 


Parameter values at time t 

m 


End of file mark 


(b) Data Frames 
FIGURE 4.10-1 (continued) 
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should be possible to define the universal format with high confidence, rather 
early in the simulation design phase. A growth margin can be allowed by leaving 
some spare capacity in each data frame. In this way, drastic redesign of the 
format, and resulting obsolescence of existing programs and data files, should be 
avoidable for the life of the program. The frame size would, of course, have to 
be consistent v/ith the block-length constraints of the host-computer operating 
system and I/O peripherals. 

In application, the universal format v.'ould be built jnto all new support 
software developed for simulation validation. This v/ould include; 

0 New reference-data generation programs {See Sects. 4, 2. 1,1, 4, 2, 1.2), 

0 “Driver" routines for simulation software modules and clusters of modules 
(see Sects. 5,1, 5.2). 

0 Routines for realtime data acquisition during operation of the all-up 
simulator (see Sect, 5,4), 

0 Service routines for reference/simulation display, comparison and evalua- 
tion (see Sects. 5.1, 5.5). 

Since a truly universal format v/ill have to be designed to accomodate high- 
volume data generation processes (up to and including an all-up high-fidelity 
simulation), there v/ill be some sacrifice in "micro-efficiency" when it is used 
for the lo’w-volume applications, such as individual modules, small clusters, and 
low-fidelity simulations, Hov/ever, this sacrifice will be counterbalanced by the 
increase in "macro-efficiency" over the entire program, resulting from the 
ability to standardize the input and output routines of all validation support 
softv'/are. An intermediate approach betiveen a single universal format and a 
plethora of custom formats would be the definition of a small number of "semi- 
universal" subset formats: one for vehicle dynamics and environment parameters, 

one for onboard-system parameters, another for simulator hardware parameters, etc. 
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Softv/are-developniGnt effort and data-base impact will be miniinlzed by the 
absence of custom data read/write routines for individual modules and module 
clusters. Finally,, data-handling errors will be minimized, both by the standar- 
dized arrangement of data on all validation data-files, and by the use of the 
header record on each data-file. 

This universal format concept has been applied with considerable success in 
the data- reduction programs Tor the Skylab Earth Resources Experiments Package 
(EREP) and the Earth Observation Aircraft Program (EOAP)-. In these programs, 
users at scattered geographic locations, vnth v/idely varying needs for data, 
benefited greatly from the standardized input/output interface provided by this 
approach. 

Reformatting Data from Existing Software 

Even if the universal data format approach is adopted for all new vali- 
dation soft, -/are, pre-existing software will have a variety of individual formats. 
Two approaches are available for integrating these programs into the overall 
validation system, and making effective use of their reference-data capabilities: 
build format conversion into the software, or reformat its data-files v/ith a 
post-processor. 

If a copy of the program is under the control of the validation staff, it may 
be feasible (depending upon the complexity of the program and the completeness 
of its documentation) to build-in compatible I/O routines. From that point on- 
v/ard, all data generated by the program will be in the universal format. 

For programs which are not under the control of the validation staff, or are 
too difficult to modify, it v;il1 be necessary to use a custom-built post-processor 
to reformat the output from the existing program. Such post-processors v/ill also 
be required for reference data which already exists in the form of a card, tape 
or disk file. 


Vr-' 
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4.11 DATA BASE It’lPACT 

A large and complex data base v/ill be built up during the simulation develop- 
ment and verification phases. This section discusses the overall organization and 
structure of this data base, as v^ell as the software, procedures and personnel re- 
quired for data base management. 

4.11.1 Data Base Organization and Structure 

Figure 4.11-1 shows in tree form the overall scope and structure of the 

V s 

validation data base. We define the data base to include information in both 
machine-readable and hard copy form. 

4.11.1.1 Ilachine-Readable Information 

Machine-readable information may be in the form of disk or drum storage, 
magnetic tape, or punched cards. Due to the great differences in costs of the 
various media, it will be desirable to distinguish between active and inactive 
data base materials, and keep only the most active in rapid-access storage. 

Active Materials 

Frequently-used materials which will need to be maintained in on-line storage 
or convenient- access tape files v/ill include: 

A. Simulation module checkpoint data, for modules currently being validated 
(See Sect. 5,1.1.) 

B. Active reference and simulation data: 

1. Module level 

2. Module "cluster" level 

3. All-up simulator 

4. Reference trajectories 

C. Active Reference modules 

D. Validation Service routines: 

1. Tabulation software 

2. Plot software 

3. Real-time data acquisition software (see Sect. 5.4) 

4. Module and cluster drivers 

5. Driver-interface data-location routine (COfTiE'J or enuivalent; see Sect. 5,1. 

6. Reference-data conversion routines (See Sect. 4.10.2.2) 

7. Comparison and evaluation routines (see Sect. 5.5) 

E. Data base managerent software 4.11-1 
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FIGURE 4.11-1. VALIDATION DATA BASE SCOPE AND STRUCTURE 
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Inactive Materials 

Lower-activity materials vihich can be kept on magnetic tape (or, for lov/- 
volume data, on punched cards) include backup copies of currently-active files 
{for recovery from possible catastrophic failures of the system hardware or soft- 
vjare)i plus check-case data and reference modules for portions of the simulation 
v;hich have passed their initial validation. These materials would be retained 
for potential use in revalidation efforts following later modifications. However, 
in some cases the modifications will invalidate the existing check-case data 
and/or dictate modififcations to the reference module. 

4.11,1.2 Hard Copy 

The hard-copy portion of the data base will, like the machine-readable 
portion, include both active and inactive elements, with similar requirements for 
access, updating and purging. The hard-copy files vnll encompass three general 
categories of information; base information, reference data, and validation 
results. The most significant information from all three categories would be 
compiled into a module-organized "validation data book". This data book v/ould 
serve as a reference for the ongoing staff, for training of new members of the 
validation staff, and for coordination with other project personnel. 

Base information (see Sect. 4.2,2) is information which is not directly 
usable as validation check cases, but supports the development of check cases 
and/or software to generate check cases. This Includes system descriptions, 
specifications, operational data books, performance parameter definitions, etc. 
Sections 4.2 - 4.7 of this report are base infoirTiation for simulation validation. 

Reference data hard copy vn‘11 include data which is not available in machine- 
readable form, as well as printouts and plots of machine-readable data made for 
engineering analysis. This will include all four categories of reference data 
identified in Sect. 4,2.'! — closed-form solutions, independent math models, 
existing analysis/sinulation programs, and test data. Recent versions of softviare 
listings will also be retained in hard-copy form. 
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Validation results will be retained in ravi form, in informal summary reports 
covering the validation of individual modules, and in formal validation reports 
issued at major milestones of the validation process , 

4.11,2 Data Base ilanaaement 

The total Data Base Management Sys te m (DBMS) includes the hardv/are (host 
computer and peripherals), support softoare, procedures, personnel, and documen- 
tation. Some of the factors to be considered in assessing the magnitude of the 
data base management problem, and thereby defining the requirements, design, and 
implementation plans for the DBMS, are as follows: 

0 The total amount of data to be handled 

0 The complexity of the data structure (i.e,, the number of “dimensions" 
of identification by v;hich a particular data item might be sought by an 
eventual user) 

0 Desired efficiency, in terms of utilization of physical facilities and 
computer resources 

0 Desired efficiency in terms of use of support-personnel resources and 
user interface 

0 Duration of the program over which the data base v/ill have to be maintained 
(ten years or more) 

0 Modularity and extensibility of the DBMS as requirements change 
0 Reliability requirements, in terms of probabilities of incorrect filing, 
retrieving, updating or purging of data 
0 Stability of the system — i.e., freedom from "crashes'* and catastrophic 
loss of data or access capability 
0 Data security 

A few of these factors are briefly discussed below. 

4,11.2,1 DBMS Requirements and Design 
Data Dictionary 

The design of any DBf5 begins with the development of a "data dictionary". 
Whether the system is manual or automated, dealing with hard-copy or machine- 
readable data or both, it cannot function effectively v/ithout a comprehensive 
data dictionary. The data dictionary simnly defines the standards for identifi- 
cation of data items as they are brought into the system, wliich in turn tells each 

user hov/ to identify an item which he is trying to get out of the system. 
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Dimensions of the. identification for an item sought may include: the subsystem of - 

interest, the name of the simulation module for that subsystem, the date or version 
of the module, the source of the reference data, the name and version of the reference 
module, identification of the check case(s), identification of a reference mission 
or mission phase, and the time period of interest during the mission. Standardi- 
zation of names and formats for these identifiers viill be required to formulate 
data requests in an unambiguous and reliable manner, and allovj efficient access 
to the desired data. 

V • 

The data dictiopiry vnll require frequent updating, especially in the early 
stages of buildup of the data base. Hov/ever, the initial definition of the 
system’s data structures and the data dictionary should be made general enough 
that it vnll not be necessary to go back later and modify the identifiers for 
data v/hich has already been filed. 

Data Directory 

A companion to the data dictionary is the “data directory", which is simply 
a list of all files and documents existing in the system as of a particular time. 

The data directory v/ill also require frequent updating, and may eventually become 
so large as to be difficult to maintain in hard-copy form. 

Query and Report Language 

The query and report language is the means of interface between the data 
base and its users and support personnel. A "query" v/ill consist of commands, 
data identifiers, end data destinations, A "report" may consist of actual hard- 
copy produced on a line printer or plotter, a display of tabular or graphical 
data on an on-line terminal, or simply making desired softv/are or data accessible 
to an application program. VMiether formulated in English-like statements or 
abbreviated numerical codes, v/hether in batch or on-line mode, user queries v-/ill 
be of forms such as: 

"Copy program xxx onto file yyy" 

"Copy xxx data-file onto unit yyy" 

"Printout xxx data-file in format yyy" 

"Get mission xxx; plot parameter yyy against parameter zzz from time t^ to time 
v;ith scale factors s-j and s,^" 


4.11-5 


MCEJOA/ft/ETt-L /%fiTfrOFJAUT!CS CO/WfVlft/V - E/ISV 


MDC Ell 36 
27 January 1975 


Data base support personnel will also need to make commands of the forms such as: 
“Add program xxx to the system" 

"Copy the data on file xxx into the system, with identifiers Ip I^" 

"Delete file xxx" 

"Replace file xxx with file yyy" 

Data Base Reliability and Stability 

The reliability (freedom from error) and stability (freedom from crashes) of 
the DBflS can obviously be no better than those of the hardware and operating system 
of the computer in which it resides (along with applications software, simulation 
software, compilers, etc.). Unless properly designed and implemented, moreover, 
they ate apt to be a good deal worsel It should be clear that the DBMS must be as 
modular and as well validated as the software it serves, if it is to make a con- 
tribution to the solution of the validation problem, rather than be an additional 
source of problems. Finally, as added insurance from crashes, backup tapes of the 
data base should be made at intervals. 

Data base stability also encompasses the idea of freedom from major redesigns 
during the lifetime of the program. This is ensured by; 

A, Building sufficient scope and flexibility into the data structure and data 
dictionary 

B, Modular organization of the data base and the DBMS, and 

C, A phased implementation of the DBtlS, enabling detection and correction of 
potential inadequacies before too great an investment is tied up in the data 
base. 

Data Security 

Data security, in the sense of prevention of uncontrolled access to data, 
may or may not be required in this application, depending upon whether JSC simu- 
lators are used to support classified (DoD) missions. Another aspect of data 
security is the prevention of inadvertant modification or destruction of programs 
and data by machine error, entry of incorrect codes, etc. CODASYL data base 
standards (see below) include provisions for both kinds of data security. 
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The probability of inadvertant destruction of data can be sharply reduced 
simply by limiting the number of people v/ho are able to enter data-modification 
coiranands. That is, data-modifi cation commands should be intercepted by the DBMS 
unless enabled by appropriate "passwords". These passwords would be known to 
data base support personnel, but not communicated to any other users of the system. 

4,11.2.2 DBMS Implementation 

It should be clear from the foregoing discussion that the development of a 
DBMS to support the development and validation of a large-scale simulator is not 
only a large task in itself, but is a task quite unlike the development of the 
simulation software. It requires different personnel capabilities, different 
computer capabilities, different language properties, and an entirely different 
conceptual base. For these reasons, v/e recommend that a thorough and serious 
"make or buy" analysis be conducted before jumping into the DBMS development, 

A v/ide variety of DBMS softv/are {much of 1t catalogued in hef. 114) is 
available on the open market — from simple file-management systems costing 
$5000 or less to full-scale DGflS/report generators costing upwards of $200,000. 

Soma of these packages have been proved in years of operating experience at 
dozens of installations, and are supported by their vendors with on-site installa- 
tion and training, extensive documentation, periodic updates, and performance 
guarantees. 

If the decision is made to proceed vn'th in-house DBMS development, v/e 
recommend that most of the lead personnel assigned to the program have extensive 
prior experience in data base design and implementation. The remainder of the 
personnel requirQr>ents can be filled by cross-training of simulation types. 

Any in-house development should also be consistent with CODASYL {Committee on Data 
System Languages) standards. This will enable the DBMS development to profit from 
the years of study expended by the CODASYL Data Base Task Group, and provide 
easier access to the most-current DBMS technology. Table 4.11-1, from Ref. 115* 
provides a few of the most important definitions of data base concepts, as for- 
mulated and standardized by CODASYL. 
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TABLE 4.11-1. BASIC CODASYL DATA BASE DEFINITIONS 


Data Item 

The smallest data base unit referenced by an assigned 
name. 

Record 

A collection of one or more data items; contains a named 
description of data items and attributes. 

Set 

’Establishes a named logical relationship betv/een two or 
,;nore record types; the basic data base building block which 
allov/s the data base designer to establish complex data 
structures. 

Area 

A named subdivision of logical address space in a data 
base; each record must reside in an area which contains 
one or more records. 

Schema 

A complete description of all data items, record types, 
set types, and areas which exist in a data base; the 
foundation ' \ a data base dictionary system. 

Subschema 

A logical subset of the schema which names only those 
record types, set types, and areas that are accessed 
by one or more specific applications programs. 

CALC 

Refers to one common method of record placement and 
retrieval within a data base; provides an access 
point via a "hashing" algorhytm. 
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SECTION 5 

METHODS FOR VALIDATING PERFORf-lANCE 


The total process of simulation validation consists of: 

1, Exercising a simulation vnth properly-chosen inputs, 

2. Gathering the output performance parameter data which it generates in 
response to these inputs, and 

3* Evaluating the simulation fidelity by comparing these data to reference 
data representing the real v/orld which the simulation is intended to 
represent. 

Techniques and support software for the efficient performance of these opera- 
tions are discussed in this section. The discussion includes overall validation 
software structure, the performance of validation at various levels of simulation 
integration, guidelines for check case formulation, methods for realtime acqui- 
sition and formatting of data from an all-up operational simulator, and methods 
and criteria for comparison and evaluation of simulation data. 
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5.1 VALIDATION SOFTWARE STRUCTURE 

Figure 5.1-1 depicts a support-software flow for the overall generation, 
handling, comparison and display of simulation and reference data as used in 
performance verification. The complete support-software system vnll consist of 
tJie validation executive shown in this figure, modelling routines as discussed 
in Section 4, and a set of service routines. Table 5.1-1 briefly discusses the 
role of each part of the overall software system. 

To reduce the amount of specialized coding and setup required to perform 
each individual validation exercise, it is desirable to build as much generality 
as possible into the service routines. Characteristics of the major routines 
are briefly discussed in the following subsections. 

5.1.1 Checkpoint Generation Routines 

Checkpoint generation routines provide a series of check case input values 
for static and/or dynamic exercise of the reference and simulation modules. The 
checkpoint generation routines will provide the user with the capability to set 
up a complete set of check cases in a convenient manner (rather than manually 
defining and entering the checkpoint data for each individual check case). It 
vnll incorporate logic to generate various combinations of discrete parameters, 
thus exercising various operational modes and logic paths of the software, as 
well as to vary continuous parameters over various ranges of values, thus 
verifying the operational envelope of the simulation. The checkpoints may be 
generated individually on-line, under control of the validation executive, or 
may be generated all at once and placed on a data file (see Sect. 4.10) for 
later input. 

As discussed in Sect. 5.3, it is generally impractical to exercise a module 
over all combinations of a sat of input values. For example, if a module has eight 
on/off discretes used for mode control, 256 check cases v/ill be required to test 
all pcssible combinations of these discretes; if it has six continuous input 
parameters, 729 check cases v;ould be required to test all combinations of high, 
nominal and lo'w values of those parameters; and 256 x 729 = 186,6241 The checkpoint 
generation routines must then nrovide flexible logic to generate only required 
and meaningful combinations of inputs. Both sysienatic and randcr.. variation 

of parameters will prove useful in nodule validation. Examples of checkpoint 
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ROUTINE 

FUNCTIONS 

Executive 

Overall sequencing, interfacing and control. 

Data read routine 

t 

» 

Reads records from a data file generated 
by a prior simulator performance run, and/ 
or a reference data generation program, 
strips data for the -appropriate module and 
places it into a data array. 

Checkpoint generation 
routine 

Generates checkpoints including all data 
required for input into the module to be 
verified. 

Simulation module 
interface routine 
(driver) 

Interfaces with the simulation software 
module, placing input and output data into 
a data array. 

Reference Module 

Generates reference performance parameter 
data, placing the input and output data into 
an array compatible with the simulation 
software data array. 

Data write routine 

Writes the data from the simulator soft- 
ware module and the reference module onto 
a temporary file, to be read back in for 
comparison processing. 

Data comparison routine 

Processes the data file previously v/ritten. 
Incorporates a variety of differencing 
techniques and connarison criteria. Per- 
forms automated comparisons of simulation 
and reference data. 

Data display routine 

Generates listings and plots of raw or 
processed data for manual interpretation. 
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generation routines are shov^n in Figs, 4,3-16 through 4.3-22, 4, 7- 11 2 and 4.7-113, 

5.1.2 Simulation Soffcvare Module Drivers 

Driver routines perform an interfacing function (analogous to the "patchboard" 
in a piece of test hardv^are). The driver obtains checkpoint inputs from an in- 
ternal array or an external data file, passes these Inputs to the simulation 
software in the proper order, format, and common locations, accepts outputs 
generated by the simulation softi-;are from their appropriate common locations, 
and places these values into an output data file for later comparison, evaluation 
and display. 

The normal interfacing method for simulation modules In their eventual 
operating environment v/i11, in most cases, be by means of a large total-simu- 
lation "common" package. Due to the size and complexity of the total simulation, 
it seems very likely that some type of support software — COMGEN (P.ef. 116) 
or equivalent ~ vnll be used for development, analysis and maintenance of the 
simulation common package. Therefore, the same interfacing mode and support 
software should be used for interfacing of simulation modules with their drivers 
and other validation service routines. Likewise, the same relative common structure 
and support softviare should be used for reference module development, thus pro- 
viding an additional area of standardization arid removing another potential 
source of error, 

5.1.3 External Data Files 

In many cases, either the reference or simulation data (rarely, both the 
reference and simulation data) will be handled as an external data file, rather 
than being generated on-l’ne during the validation exercise. The validation 
exercise, in turn, v/ill typically generate a ne^; external data file, consisting 
of interleaved reference and simulation data vs. time, for post-processing by 
comparison, evaluation and display routines. Sorre of these data files v/ill be 
"volatile" (i. e., discarded soon after processing is complete), while others 
will be retained in the data base for varying periods of time. 
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Section 4.10 discusses generation and formatting of reference data files, 
either by nev/ly-developed reference modules or by use of existing analysis/simu- 
lation programs adapted for validation purposes. Section 5.4 discusses the 
generation and formatting of simulation data files by realtime acquisition 
of data from an operational all-up simulator. In both applications, it seems 
clear that the magnitude of the analysis', development and maintenance efforts 
will be minimized, and the occurence of errors in data-handling sharply reduced, 

t 

by the use of standard or "universal" formats for all data files in the system. 

* I.. 
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5,2 MODULE INTEGRATION 

Simulator validation is performed at various stages of integration during 
the course of simulator development. This is true whether integration and 
validation are conducted in "top-down" or "bottom-up" fashion. This section 
defines four configurations of simulation software linked with validation support 
software which can be used for the exercises required for performance verification, 
and discusses the utility of each of these configurations in accomplishing total- 
simulation validation. 

* 

t* ^ 

5.2.1 Configuration Definitions 
Isolated Module 

For the present purpose, a "module" is defined as a "set of software elements 
which is invoked as a unit -and performs a defined function." Any single module of 
simulation software can be verified in isolation by use of a properly-designed 
"driver" {interface routine) with appropriate static and/or dynamic check cases. 

To do this, the driver must substitute for all other modules which, in the eventual 
integrated simulation, will interface with the module under test. That is, the 
driver must provide all continuous and discrete inputs needed to initialize the 
module and control its execution, as well as exercise it for performance 
verification. These inputs must be properly scaled, formatted and routed (by 
use of argument lists and/or common- storage locations). Similarly, module outputs 
must be scaled, formatted and routed for storage, manipulation, comparison and/or 
display. 

. Integrated "Cluster" of Modules 

Two or more naturally interacting modules can be operated together by a 
single driver, thus providing for each other some of the data, control , and I/O 
functions which would otherwise have to be provided by the driver. Section 4.8 
provides examples of natural clusters of modules. The limiting case of cluster 
testing is off-line (non-realtime) operation of the total software system without 
its simulator hardware interfaces. 

The exercise of an integrated cluster could conceivably be the initial 
validation for all of the modules in the cluster; more commonly, hov;ever, some or 
all of the modules will have previously been individually validated more or less 
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thoroughly, either in isolation or as part of a different cluster. 

Figure 5.2-1 provides examples of dynamical check cases {step-input responses) 
which could be run on a cluster consisting of aerodynamics, vehicle dynamics and 
environment, together with an appropriate driver. 

Modified All-Up Simulator 

During initial integration of the simulator software and hardware into an 
operable all-up simulation, temporary modifications can be made for verification 
purposes. Two types o'f modifications are considered: 

e Emplacement of "probes" or "test points" for insertion of stimuli and/or 
tapping of responses at points which would not normally be accessible via 
standard output. 

9 Interruption of normal signal flow within the simulation system, to 

artifically decouple various interacting functions (e.g., the aerodynamics 
from the equations of motion) and thus simplify signal/error propagation 
characteristics. 

The first approach is used, for example, at NASA-LRC; control commands from 
a "canned man" (a data tape) are inserted downstream of the manual controls. This 
ensures check case repeatability and objective evaluation of simulation performance. 
Both approaches are to be used in the acceptance testing of the USAF F-15 simulator 
now being developed under the aegis of McDonnell Aircraft Company. 

I 

Interrupted signal flows must of course be reconnected to return the 
simulator to normal operation. Certain of the test points, however, might 
profitably be left in place permanently, for convenience in reverifi cation efforts 
following later modifications. 

Normal All-Up Simulator 

The complete man-in-loop simulator, in its normal operating configuration, 
can be exercised by check cases of two different kinds: 

« Specially-constructed test cases (not necessarily representing any 
anticipated real-world mission or mission phase), providing rigorous 
exercise of the simulation, high repeatability, and easy interpretability 
of results. 
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FIGURE 5.2-1. EXAMPLE CHECK CASES FOR A SMALL CLUSTER OF MODULES. 
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® Realistic mission/mission phase check cases; e.g., a reference mission, 
an anticipated future mission, or a re-enactment of a previous mission. 

5,2.2 Pros and Cons of Defined Configurations 

The four test configurations just described are often considered as the 

normal evolutionary stages in validation of simulators; every module would be 

expected to pass through all four states in turn. It is also often assumed that 

a "complete" verification of all possible functions is performed at each stage, 

before proceeding to the next. Thus, isolated-module configurations would be 

(» 

used to verify all functions of individual modules, so that when they were 
integrated into clusters, all that would remain to be verified would be their 
relative interfaces and interactions. This is the traditional "bottom-up" 
integration/validation methodology. 

Recent advances in software-development methodology, particularly an 
increasing emphasis upon "top-down" testing, make it appropriate to question 
these conventional assumptions, and to consider whether, for some modules, it may 
be reasonable to de-emphasize isolated-module validation in favor of validation 
at a higher level of integration. Table 5.2-1 provides an objective look at 
the capabilities and limitations of validation exercises performed at each of 
the above-defined levels of integration. These considerations are essential to 
any effort to allocate overall simulation validation effort. 
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table 5.2-1. 


CONSIDERATIONS RELEVANT TO^ PERFORMING VALIDATION AT VARIOUS LEVELS OF INTEGRATION 


VJ,lIDATION 

CONFI&ijRATIO'l 

PRIKARY OBJECTIVE 

ADVAiiTAGES 

DIS ADVAiiTAGES 

Isolalei! “odule 
'sofV.are only) 

To Validate Petal led 
5i"’jlation Capabili- 
ties of each itudule 

Easiest to devise check cases for which correct answers are 
known exactly. 

Easiest to faul t-isolate following check-case failure®. 
Easiest to ensure thorough exercise of module. 

Can he executed offline (batch runs). 

Generation of each driver represents extra coding and de- 
bugging effort. (Developiient of "general -purpose” drivers 
will reduce the cumulative effort, but sar.e tailoring of 
the driver to each reodule under test will still be necessary.) 

For "trivially" siiiple modules, the validation benefits may 
not be enrnoensurate with the effort of building the driver 
and setting up and executing the check cases. 

Does not explicitly verify module-to-riiOdLle interfaces. 

Integrated 
'.Ijster of 
■ -djlBS 

[icfiware only) 

To Validate Inter- 
faces Aihong Hlghly- 
Interactive fiodules 

Driver can be simplified, because some required data is 
supplied by modules in the cluster. 

less Cumulative coding and debugging effort devoted to 
generation of drivers; a sirigle driver serves validation 
of mu1 tiple modules , 

All exorcises are “non-trivial". 

Verifies some module- to-nndule linkage. 

Can be executed offline (batch runs). 

May be difficult in thoroughly exercise and validate all 
modules in the cluster. 

Hay sometimes be difficult to devise test cases for which 
correct answers are kiiov/n exactly. 

May sometimes be difficult to fauU-isolate following 
chock-case failure®. 

'•' 0 ‘ilfied all-up 
SI "ulator 
(hardware and 
software) 

To Simplify Signal 
Error Propagation for 
Systert-Level 
Va1 idation 

Ho coding and debugging cf drivers- 

Allows extensive verification of module-to-module linkage. 

May be a complex, laborious process to (codify and restore 
Simulation, and to set up for check-case ’execution. 

Potential for later difficulties If all modifications are not 
restored to nonval configuration. 

Requires realtime operation of dedicated system. 

Difficult to know correct answers for all variables which 
will be exercised by cacl| check case. 

Difficult to faul t-isolpte following check-case failure®. 

Few individual simulation modules will be thoroughly exercised. 

Difficult to obtain repeatable results from man-1 n-1oop 
operation. 

Normal all-up 
simulator 
(harduare and 
software) 

To Validate Dynamic 
Adequacy of Total 
Simulator System 

No coding and debugging of drivers. 

Allows convilete verification of hardware and software 
Interfaces. 

Successful operation builds confidence In complete simulator 
system. 

Contributes to simulator acceptance®. 

May be a cou.plex, laborious process to set up simulator for 
check-case execution. 

Requires realtime operation of dedicated system. 

Difficult to know correct answers for all variables exercised 
by each check case. 

Very difficult to fault-isol ate following check-case failure®. 
Few, individual simulation modules will be thoroughly exercised. 

OifflcuH to obtain repeatable results from man in-loop 
operation. 


®Hot expllcttly 1n the scope of this study. 
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5.3 CHECK CASE FORMULATIOn 

This section deals with the problem of providing a thorough validation 
exercise of a simulation in an efficient manner. Thoroughness is essential 
to provide high confidence that the simulation vn'll function properly over 
its entire range of operation, and for long periods of time. Efficiency is 
essential because the simulation is large and complex, and validation will 
require large expenditures of computer and personnel resources. 

The topics covered in this section are check case design principles, 
application of these principles to initial validation of modules and integrated 
simulations, and application to revalidation of modules and integrated simu- 
lations. Interestingly enough, the same principles lead to diametrically 
opposite approaches for initial validation vs. revalidation. 

5.3.1 Check Case Design Principles 

Criteria for selection/construction of a set of check cases include thor- 
oughness, efficiency, and order of execution; implementation methods include 
manual selection, complete and incomplete factorial designs, orthogonal designs, 
and random ("onte Carlo) variation of parameters. 

5. 3. 1.1 Thoroughness 

It is convenient to visualize the jperational range of a particular simu- 
lation as a "parameter space" — the range of values which its input parameters 
(including time) are allowed to assume. The process of validation exercise then 
consists of supplying check case inputs which "sweep out" the parameter space 
over a broad enough range and at a close enough spacing that we become confident 
that the simulation will perform properly vjhen given any input lying in that 
space. Discrete and continuous regions of the parameter space must he considered 
separately. 

Discrete regions of parameter space arise vjhen a simulation has internal 
logical breaks which result in different modes of operation for different values 
of its input parameters. These internal logical breaks may be activated either 
by input of discrete variables (failure flags, switch settings, etc.), or by 
input of continuous variables whose values cross over certain breakpoints in the 
logic (e. g. , altitude ranges in an atmosnhere routine, i.ijch-number ranges in 
aerodynamic tables). 
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The range of variation of continuous input parameters should reflect the 
spectrum of missions for which the simulator will be used, including nominal, 
off-nominal, failure and abort cases. V/ithin the simulation module, variation 
of the values of its continuous input parameters may result in variations in 
amplitude, frequency, linearity, or other attributes of its response in a 
smoothly-varying manner, rather than by discrete switching between modes of 
response. 

5. 3. 1.2 Efficiency *' 

Efficiency in this context refers to minimizing to the expenditure of com- 
puter and personnel resources needed to attain a certain level of confidence 
in the fidelity of the simulation over its entire operational range. Efficiency 
can be gained in tv/o v/ays: 

0 By minimizing the total number of check cases needed to attain a given 
level of confidence, and 

0 By minimizing the resources needed to generate, execute, and Interpret 
each individual check cr’se. 

The second approach is discussed in other sections of this report. 

useful viewpoint for attacking the minimization of the number of check 
cases is the economic concept of "marginal utility". The marginal utility of a 
check case is the increase in confidence derived if it executes successfully, 
or the diagnostic information derived if it fails. To maximize the marginal 
utility of each check case, it is necessary to minimize inter-case redundancy. 

That is, each additional check case must be made sufficiently different (in a 
meaningful way) from previously-executed check cases that it provides new infor- 
mation about the module performance, rather than just reconfirming what has already 
been demonstrated. 

Although in practical cases it is difficult to quaiitify the marginal 
utility of a check case (or even to quantify the current level of confidence in 
the simulation), even an intuitive understanding of the concept will help to 
prevent over-validation in some regimes of operation at the expense of under- 
validation in other regimes of equal importance. In conducting parametric 
studies resulting in performance curves, for example (see Sect. 4. 9, 2. 2), tf e 
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input points should be spaced just closely enough to define the shape of the 
curve, as predicted from preliminary analysis or test data — not necessarily 
closely enough to draw a smooth curve starting from scratch. 

5. 3, 1,3 Order of Execution 

Obviously, the marginal value of a particular check case depends not only 
upon the properties of that check case itself, but also upon the check cases 
v;hich have previously been executed. To define an "optimum" ordering of 
check cases, it is heTpful to consider what will be knov‘/n, and what decision 
vnll result, if each check case passes, or if it fails. The cost of that 
decision or stai'^ of knowledge is then the cumulative cost of all check cases 
which have been executed up to that point. This viewnoint has different impli- 
cations for initial validation and revalidation. 

5.3,1 „ 4 Basic Check Case Selection/Construction Methods 

Four basic methods of constructing sampling points in a parameter space 
are the complete factorial, incomplete factorial, orthogonal, and random methods. 
These four methods are shov/n for tv/o- dimensional space in Fig. 5.3-1; however. 

It is important to realize that the parameter spaces in simulation validation 
v/ill be many-dimensional. 

In a complete- factorial parameter- variation scheme, every possible combination 
of parameter values (for a fixed spacing in each dimension) occurs exactly once. 
Thus, the checkpoints define a more or less closely-spaced grid spanning the 
parameter space. As the number of dimensions increases, the number of checkpoints 
increases explosively. For example (see Sect. 5.1.1), running all combinations 
of low, nominal and high values for six continuous parameters, and all combinations 
of on/off values for eight discretes will require 186,624 checkpoints. In an 
incomplete- factorial scheme, the checkpoints still lie on a grid, but some of the 
grid points are void. Although every individual parameter takes on every possible 
value (for the given grid spacing) at least once, many possible combinations of 
values do not occur. 


5.3-3 




MDC Ell 36 
27 January 1975 


f. 



(a) Complete Factorial 


(b) Incomplete factorial 


S 



(c) Orthogonal lines 



(d) Random 


FIGURE 5.3-1 TUO-DirCitSIOflAL ILLUSTRATIOflS OF FOUR 
METHODS OF CHECKPOINT GENERATION 

(RECTANGLE REPRESENTS PARAMETER SPACE, S.) 


5.3-4 


TVJCrfONtVELL OOUCSt-AS jetSTWOBJ/SUT-rCS CCKVtFf/ltVV m G^aST 






MDC £1136 
27 January 1975 


The orthogonal -line method 1s a further extension of the Incomplete factorial 
concept. Here all checkpoints lie on perpendicular lines, extending out to the 
boundaries of the parameter space. The orthogonality of the lines tends to 
achieve the goal of maximizing the difference betv/een checkpoints, and the 
limitation to these lines sharply reduces the total number of check cases, as 
compared to factorial schemes. If the lines are skevjed relative to the coordi- 
nate axes of the parameter space, the basic benefit of the factorial schemes — 

the use of combinations of parameter variations — is retained, 

* 

Random or Monte Carlo variation of Input parameters Is Inefficient for 
parameter spaces of few dimensions, but research In optimization methods has shovm 
that the relative efficiency of Monte Carlo methods improves as the dimensionality 
of the problem increases (Ref. 117). Historically, Monte Carlo methods have 
been of greatest value In attacking complex problems which proved impractical 
to solve by more systematic methods (Ref, 118). The checkpoints may be generated 
by a uniform distribution (1, e., with equal probability of falling anywhere In 
the parameter space), or may be distributed more densely either In the nominal 
operating regime or near the extremes, whichever is desired. 

All of the above-described methods are suitable for implementation in auto- 
matic checkpoint-generation routines. Check cases may also be generated manually, 
either using one of these basic methods, or based upon the analyst's intuitive 
understanding of the system and its simulation requirements, and a "feel" for 
what choices of input parameter values will provide the most information about 
the simulation fidelity. 


5,3.2 Check Cases for Initial Validation 

Check case ordering Is an important aspect of Initial -validation strategy, 
both for modules and Integrated simulations. The ordering of check cases for 
initial validation should result in a more-or-less gradual process of expanding 
the envelope (by analogy to hardware testing and vehicle flight testing). This is 
based upon a pessimistic initial assumption (since nothing has yet been proven 
about the module's capability) that, for some or all of its required operational 
range, the simulation will fail to perform satisfactorily. When it does fail, 
it must be fixed, and some or all of the previously-executed check cases repeated. 
Therefore, v'e v/ouM like to minimize the resources expended up to the point of 
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failure. Figure 5.3-2 depicts, in general terms, the relationship beti*;een objec- 
tive confidence level and the number of check cases executed, for initial simula- 
tion validation. 

5. 3.2.1 Initial Validatiou of Individual Modules 

The first check case(s) presented to an individual module should verify 
some minimal operational capability — the simplest logical flow, most linear 
regime, etc. {'Again by' analogy to hardware testing, this is sometimes called a 
"smoke test" (Ref. 119); '‘plug it in and see if it smokes.") Successive cases 
become increasingly more rigorous, until the complete envelope has been attained. 

The output data density also varies during the course of module validation. 
Most or all of the performance parameters would be output in the early stages, 
gradually scaling down to just the critical performance parameters as validation 
progresses successfully. Failed check cases would probably be rerun with more 
complete output for diagnostic purposes. 

5. 3.2.2 Initial Validation of Integrated Simulations 

At all stages of simulation integration (see Sects. 4.8, 5.2), the operational 
modes of the individual modules, as well as the types and values of inputs they 
receive, are determined basically by the overall mission phase and vehicle opera- 
tional mode. Therefore, integrated-simulation check cases should be mission- 
oriented sequences. 

The process of envelope expansion in this context v/ill consist of execution 
of longer, more complete, and more rigorous mission segments. Starting vnth a 
“mini-phase" or mission-phase segment, v/ell within the nominal operational regime, 
the duration would be extended out to include a complete mission phase, at the same 
time that the forcing parameters — trajectory parameters, failures, etc. — are 
made more extreme, when operational capability has been verified for mission 
phases individually, the capability to progress from one phase to another, and 
from nominal operation to abort modes, should then be verified. 
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FIGURE 5,3-2. COMFIDEHCE RELATIOMSHIES FOR INITIAL VALIDATIOH 



FIGURE 5.3-3. COJIFIDEHCE RELATIONSHIPS FOR REVALIDATION 
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Most integrated-simulation validation will be based upon output of critical 
parameters only* For diagnostic purposes in the event of check-case failure, 
complete performance parameter output from suspect areas may be obtained. However, 
complete output of all performance parameters of the simulation may not be possible 
within realtime constraints (see Sect, 5.4). In any event, a powerful data-handling 
system will be required to make effective use of so much data. 

5,3,3 Check Cases for Revalidation 

By contrast to the initial validation problem, revalidation strategy should 
be based upon the optimistic assumption (due to prior successful experience with 
the simulation before it v/as modified) that it will perform satisfactorily over 
its required operational range. Therefore, revalidation Is treated as a process 
of envelope contraction . The process is started by executing a small set of 
check cases (Ideally, a single check case) which, if successful, will verify 
both the nomimal and extreme operational capability. 

If the initial test results in one or more failures, progressively less 
rigorous exercises are performed, until the root of the failure is uncovered. 

Figure 5.3-3 depicts the relationship betv;een objective confidence level and the 
number of check cases executed, for simulation revalidation. 

The data density is low for the initial test (critical performance para- 
meters only), and Increased only for diagnostic purposes in the event of failure. 
Check case "failure," of course, may be due to improper implementation of the 
simulation modification,, or may simply mean that the old check case (retained 
in the data base) has been invalidated by the modification. 

5, 3. 3.1 Module Revalidation Check Cases 

The initial check case for revalidation of a simulation module should be a 
fairly long time-sequence of discrete and continuous inputs which forces the 
module to select all of its operational modes, perform in Its nnminal operational 
regime, and operate out to its specification limits. 
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5q 3,3,2 Integrated Simulation Revalidatlon Check Cases 

Depending upon the magnitudL and type of modification made, revalidation check 
cases for the integrated simulation may be either complete mission phases or a 
short but complete end-to-end mission (either a once-around mission or a return- 
to- launch -site abort). Table 5,3-1 suggests the scope of potential mission/mission 
phase check cases for revalidation. 

Each such check ease should provide a rigorous exercise of the all-up system, 
in terms of trajectory parameters, maneuvers, visual and motion-base exercise and 
synchronization, etc. Manual inputs, such as stick motions and sv/itch settings, 
should be provided by a "canned man" (a pre-recorded data file) for check case 
repeatability. For rapid and accurate evaluation, the maneuver sequences should 
result in easily-recognizable decision points — out-the-v/indow viev/s. Insertion, 
touchdown, stopping point on runv/ay, etc. 

As with all integrated-simulation operations, validation outputs should be 
limited to the critical performance parameters. 
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TABLE 5.3-1. SUP1MARV OF MISSIOM/MISSIOH PHASE CHECK CASES. 


f.l!SS10»/'f,llSSI0H PHASE 

DESCRIPTION 

TYPICAL PERFORI/IANCE PARAMETERS 

. LAUNCH TO TOUCHDOWN 

0 TOTAL SPACE frtlSSION VOUCH INCLUDES ASCENT, ONE OROIT 
REVOLUTION, ENTRY, TAEH AND AUTOLAND 

B AHITUDES AND RATES, ALTITUDE, MACH HO„ RANGE, RANGE RATE, 
AHGLE-OF-ATTACK, 

o ASCENT 

« FLIGHT IN THE ATMOSPHERE POWERED DY BOOSTER SOLID ROCKET 
MOTORS AND OROITER MAIN PROPULSION TO ORDIT INSERTION. 

« ATTITUDES AND RATES; AL1 ITUDE AND ALTITUDE RATE, DOWNRAHGE, 
SLANT RANGE, VEHICLE VELOCITY. 

. QN'ORBtT 

• CIRCULAR OR ELLIPTICAL EARTH ORDIT WHICH CAN INCLUDE ANY 
ONE, Aa OR NONE OF THE ON-ORBIT TtlANEUVERS 

• ATTITUDES AND RATES; ORBITAL VELOCITY & ALTITUDE, PROPELLANT 
USAGE 

-RENDEZVOUS 

- PHASE WHICH BEGINS WITH FIRST CATCH-UP MANEUVER AFTER 
INSERTION and CONTINUES THROUGH DRARIHG AND DOCKING 

• TARGET EPHEMERiS, RENDEZVOUS TIME, RANGE, RANGE RATE AND 
ELEVATION ANGLE 

-STATION KEEPING 

- INSPECTION on WAIT PERIOD IN THE VICINITY OF THE 
TARGET VEHICLE 

B RANGE, RANGE RATE, LINE-OF-SIGHT RATES 

- PAYLOAD HANDIIKG 

- DEPLOYMENT AND RETRIEVAL PROCEDURES FOR QH-ORBIT 
PAYLOADS 

B PAYLOAD AHITUDE, RANGE, RANGE RATE, PAYLOAD SUBSYSTEM 
PARAMETERS 

» EMTRY 

« PORTION OF THE ARBITER FLIGHT WHICH INCLUDES THE OEORDIT 
MANEUVER THROUGH THE START OF THE SUBSONIC FLIGHT 
REGION. 

o ANGUE-OF-RTTACK, RANGE, RAflGE RATE, MACJl NO., ALTITUDE 
DYNAMIC, PRESSURE, AERODYNAMIC HEATING RATES. 

• TAEM 

« THAT PHASE OF THE ORDITER'S REENTRY TRAJECTORY WHICH 
STARTS WITH THE SUBSONIC FLIGHT REGION AND CONTINUES 
TO FINAL APPROACH. 

• ANGLE-OF-AnACK, BANK ANGLE, SPEED BRAKE POSITION, MACH KD., 
ALTITUDE, HEADING, RANGE. 

/ 

• AUTOLAND 

• MISSION PHASE BEGINNING WITH THE FINAL APPROACH AND 
CONTINUING THROUGH LANDING, ROLLOUT AND BRAKING. 

• ALTITUDE, SINK RATE, GLIDE SLOPE ERROR, LOCALIZER ERROR, 
PITCH, ROLL, YAW AND CORRESPOHDIHG RATES. 

• FERRY 

B TOTAL AEROFLIGliT MISSION WHICH INCLUDES TAKEOFF, 
CRUISE, APPROACH, mHUAL LANDING, ROLLOUT AND BRAKING. 

• ANGLE-OF^ATTACH, ALTITUDE, MACH NO., PITCH, ROLL, YAW A 
CORRESPONDING RATES, FLIGHT PATH ANGLE. 
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5.4 REALTIME DATA ACQUISITION AND F0RIWTIN6 

This section discusses requirements and techniques for realtime acquisition 
of performance parameter data from an operational all-up spacecraft simulator. 
Although such data may be used for on-line manual monitoring or "quick look" 
assessment of simulation performance, the basic purpose of the data is for 
validation post-processing. 

4 

Reference 120 describes a similar application of realtime data acquisition 
on the Shuttle Procedures Simulator, undertaken in support of the Crev; Procedures 
Development Techniques Study performed at NASA-JSC, 

5,4.1 Data Acquisition Requirements, Goals and Constraints 

The basic purpose of the realtime data acquisition subsystem is to build 
a properly-formatted data file of time- tagged data — flight crew inputs and 
simulation performance parameters — for later processing by validation service 
routines. As a secondary function, it may be desirable to provide summary in- 
structor/operator station CRT displays for on-line monitoring of the most critical 
aspects of simulation performance, or for "quick look" assessment of simulation 
performance immediately after a simulator run. 

Since the data may be intended for use in 'initial validation, revalidation, 
or problem diagnosis, the data acquisition subsystem must provide capabilities 
for convenient variation of data density, both in terms of the number of para- 
meters recorded and the sampling frequency; see Sect. 5,3. The data file must 
be formatted in a manner consistent v/ith other validation data files (see Sect, 
4.10); that is, in time- tagged “pages" or "frames" of data of standardized arrange- 
ment and format, preceded by a header frame of standardized type, and ending with 
a standard end-of-file flag. 

The data acquisition subsystem must be properly synchronized vnth the real- 
time simulation eKCcutive, such that all data recorded in a particular frame is 
actually updated as of the time shovm in that frame. It must have access to all 
simulation data common- storage areas, and appropriate data buffers and I/O 
channels. Most importantly, the data acquisition system must not interfere v/ith 
realtime simulator operation, either by pre-empting required main storage or by 
preventing the simulation from keeping up v/ith real time. 
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5,4.2 Data Acquisition SubsysteTii Design and Implenentatlon 

Overall control, storage, and Input/output relationships for the realtime 
data acquisition subsystem are sketched in Fig. 5. 4,-1. 

5.4.2. 1 Data Acquisition Control Module 

The control module performs interfacing and synchronization with the simu- 
lation, and controls buffering, manipulation and transfer of data to the output 
file. Prior to the start of the simulation run, the control module performs the 
following initialization functions: 

(a) Accepts inputs defining the desired data density (number of output parameters 
and“sampTing frequency) and instructions for formatting the individual para- 
meter values and mapping them onto the output data frames. This Information 
is then written onto the data-file header block (see Sect. 4.10), 

(b) Establishes linkages to the simulation common-storage blocks. This would 
probably be achieved by use of the same basic common package support soft- 
v;are used for the simulation (COMGEfl or equivalent; see Sect. 5.1.2). 

(c) Establishes linkages to the buffer areas and input/output channels provided. 
This v;ould normally be controlled by the host computer operating system, 

5. 4. 2. 2 Operational Interface v/lth Realtime Simulation 

Upon receipt of each ’’transfer enable" discrete from the simulation executive, 
the data acquisition control module accesses the desired parameter values from com- 
mon storage, and loads them into the buffer area. It may also be necessary to 
pick up certain hardware-related variables (e. g., switch settings, visual and 
motion-system parameters) from simulator I/O channels. Depending upon the update 
cycle of the simulation software, multiple transfers may be necessary to acquire 
all of the data required for a particular frame. 

To prevent data acquisition from interfering v;ith simulator realtime operation, 
it may be necessary to restrict the size of the data acquisition software and its 
associated buffers to conserve main storage, and/or to restrict the data-density 
to conserve execution tins. During execution, the priority of the data acquisition 
function must be set low enough that data-acquisition operations can be deferred 
or interrunt'^d ir. the event that the simulation threatens to lose synchronization 
with real time. This would lead to "dropouts" on the data file, and some com- 
promise of its usefulness for validation. Such occurrences should be flagged by 
the control module. 5,4-2 
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FIGURE 5.4-1 REALTIf€ DATA ACQUISITION SUBSYSTEM FUNCTIONAL 
ELEMENTS AND INTERFACES 
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5. 4, 2. 3 Data Buffering 

A buffer area in main storage must be provided to hold newly- acquired data 
while it is manipulated for formatting and output. This buffer area must be 
large enough to hold a complete frame at one time, since output will be in terms 
of complete frames. 

6.4.2.^i Data Manipulation 

Using the instructions loaded at initialization time, the data acquisition 
software will take da^a from the buffer area, format it for output or display, 
and transfer it out on the appropriate output channel. In its primary opera- 
tional mode, generation of a data file for validation post-processing, the 
formatting operations will consist of: 

0 formatting of individual data items (scaling, fixed-point and floating- 
point formatting, packing, etc,), and 

0 frame generation (ordering outputs for the current frame, multiplexing, 
etc,) 

If secondary capabilities for realtime display are implemented, the selected 
parameters from the buffer area v/ill also be put out onto tabular CRT displays 
at selected update rates (consistent with human reading-speed limitations). 
Display updates could be performed at fixed intervals, on the basis of the amount 
of change in the parameters of interest, or upon the occurrence of certain 
discrete events. Realtime graphical displays may also be provided, if sufficient 
computational time is available. Quick-look graphical displays could easily be 
generated when the simulator is in "hold" mode. 
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5.5 COMPARISON METHODS AND CRITERIA 

When the reference data and simulation data for a particular check case or 
set of check cases are both available in machine-readafalej compatible form^ the 
comparison and evaluation may be implemented in either of two ways: 

(a) Use the validation support software to display the reference and 
simulation data in a form designed to enhance the earje and reliability 
of manual comparison and evaluation. 

(b) Perform automatic comparison and evaluation within the validation support 

I 

software. 

V ^ 

Automated comparison/evaluation is desirable on grounds of accuracy, internal 
consistency, speed, and of course, cost. To be useful, however, it is essential 
that automated comparison/evaluation methods give results which are consistent 
with the subjective j'udgement of experienced simulation engineers. 

Whether the comparison is performed manually or automatically, the level of 
fidelity which is considered acceptable will vary for different modules, and for 
different operational ranges and modes of a single module. For all modules, the 
criteria for acceptability will becom'e more demanding as a function of time, as 
the vehicle, subsystems and environment become better defined, and higher- 
confidence reference data becomes available. 

Whenever the fidelity of a particular module is j'udged to be unacceptable, 
the normal response of the simulation staff would be to attempt to obtain acceptabl 
fidelity by tinkering with the "characteristic parameters" (gains, time constants, 
and other coefficients) of the simulation module, before attempting a basic 
redesign of the module. Although such techniques are not strictly within the 
scope of this study, they are briefly discussed both for manual and automated 
comparison methods. 

5.5.1 Display Methods for Manual Comparison 

The validation support software must provide a variety of tabulation, 
plotting and processing capabilit'es to present the reference and simulation data 
in formats enabling efficient manual comparison and evaluation. 
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5. 5. 1.1 Tabular Displays 

Tabular displays, although Ineffective for time-history data, are useful for 
highly accurate single-point comparisons of reference and simulation data; for 
example: 

0 The times at which certain discrete events occurred. 

s Vehicle state variables at the end of a particular mission phase or 
maneuver sequence -- ascent, rendezvous, etc. 

9 Summary or end-po1nt variables, such as consumables. 

c Fixed-time comparison of matching variables from^ replicated modules, 
such as IMU gimbal angles or bus voltages. 

5. 5. 1.2 Raw-Data Plots 

The most useful presentation for manual comparison/evaiua-:ion vi/ill be time- 
history over plots of reference and simulation data on the same axes, as shown 
in Figure 5.5-1 This plot is scaled to give maximum resolution for the available 

picture area, which results In uneven scale parameters. If ease of interpolation 
or intercomparison of various plots in a set of data were desired, it would be 
necessary to use preassigned scale factors. The support softv/are must therefore 
offer a variety of formatting and scaling capabilities, including logarithmic 
scaling for parameters of broad dynamic range (e.g., atmospheric density). 

Interpretation of time-history plots to modify module parameters for a better 
match will require consideration of individual attributes of the response, such as 
initial mismatch, oscillation frequency, damping, phase error, and steady-state 
error. The subjective "weighting" assigned to the various attributes of the 
simulation response will depend upon the context. For example, if the parameter 
is to be integrated, steady-state error might be most important; but in a motion- 
base or visual system, the initial response would be most important as a source 
of cues to the pilot. 

Depending upon the familiarity and complexity of the system, it may be 
fairly obvious v/hich parameters should be changed to improve each attribute of the 
response, or considerable experimentation may be required. This type of experi- 
mentation is best done on via on-line graphic-display terminals (which v/ere used 
vn'th cohsiderable success in the DC-10 performance monitor development program). 
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Therefore, the validation support system should include this software and hard- 
ware capability. 

5. 5. 1.3 Difference and Error Plots 

Numerical differencing (differentiation) can be used as a check on smoothness 
of a module's input/output response, in those cases where a module has discrete 
switching between modes of operation, or uses a piecewise fit to cover its overall 
dynamic range (e.g,, atmosphere and aerodynamic routines). Figure 5*5-2 shows 
the appearance of i "^regularities at boundaries of the piecewise fit used in an 
atmosphere routine, as amplified by the use of numerical differencing. 

It is also sometimes convenient to generate a plot of the error between the 
simulated and reference data, appropriately rescaled. Fixed or percentage tolerance 
bands can be simultaneously plotted on the same axes to aid evaluation. 

Figure 5,5-3 shows an example error plot for an atmosphere routine. 

As with the raw-data plots, linear, logarithmic and other foras of scaling 
may be used, as appropriate to the range and type of parameter variation. 

5.5. 1.4 Parameter-Plane Plots 

The "parameter plane" or "calibaration curve" format may be used to advantage 
for certain static cf sck cases resulting from a parametric study. In this format, 
illustrated in Figure 5,5-4 , the reference value and simulation value for each 
checkpoint are used as the plotting coordinates. Thus, a perfect match between 
reference and simulation data, over the range of interest, v/ill put all plotted 
points on a diagonal line of unit slope (shown dashed in the figure). Bias, scale 
factor, and other forms of error v/ill result in departures from this ideal line. 
Fixed or percentage tolerance bands can also be placed on the parameter-plane plot, 
as shov;n. 

A special form of parameter-plane plot, which is useful for summarizing large 
quantities of essentially static data, is the contour plot, in which contours 
of simulation error value (or pevcentage) are plotted against two of the input 
parameters of interest, over a range of variation. Use of the contour plot, 
where appropriate, can focus attention upon the regions of greatest Inaccuracy of 
a simulation module. A hypothetical example is shown in Figure 5.5-5 . 

5.5-4 
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FIGURE 5.5»3. EXAMPLE SIMULATION ERROR PLOT (ATMOSPHERE ROUTINE). 
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5,5.2 Automated Comparison Techniques 

Computers are, of course. Incapable of making subjective judgements about the 
"goodness" of the match between reference and simulation data. An automated 
comparison/evaluation program will perform some processing (which may range from 
elementary to quite complex) of the reference and simulation data, resulting in one 
or more numbers which quantify the degree of mismatch. The mismatch value(s) are 
then compared against criterion values provided by the validator, and the 
simulation is thus classified as acceptable or unacceptable. 

The experience and judgement of the validator are, of course, embodied in the 
selection of the criterion values used to separate acceptable from unacceptable 
performance. As stated above, the acceptance criteria will vary for different 
modules, for different operational modes and regimes, and as a function of time. 

Variation of simulation module characteristic parameters to improve the 
match can easily be automated, since all quantities involved in the process are 
available to the computer in numerical form. The match between simulation and 
reference data can be "optimized" (relative to the comparison technique in use) 
either by systematic or random perturbation of the module characteristic para- 
meters. Descriptions of optimization algorithms (stepwise variation, gradient 
search, Monte Carlo, etc.) are widely available in the literature. 

# 

5. 5. 2.1 Tolerance Bands 

A very simple routine can be used to find the maximum error between the 
reference and simulation data, 

^max ^ {lr(t)-s(t)|: O 4 : t ^ t] 

and compare this to a preassigned tolerance. In some cases — where the data 
covers a vn'de dynamic range, but does not pass through zero — it will be 
appropriate to use the maximum percentage error, rather than the maximum absolute 
error. 

Where smoothness at certain representational boundaries is an important 
criterion of simulation quality, tolerances may be applied to the first and/or 
second differences (derivatives) of the simulation data. 


5.5-9 


■rSTCOOWfUETLlL. -OOtJ'GZ.AS /3rSTErOiWat/TtfeS CO/WFVin/V - EAST 


MDC Ell 36 
27 January 1975 


5. 5. 2.2 Integral Criteria 

A variety of simple integral transformations may be used to convert the 
mismatch between reference and simulation time-history data into a single number 
for evaluation purposes. Several of these transformations are listed below: 

Integral of error: Y 

IE = ^[r(t)-S(t)]dt 

Integral of absolute .error: Y 

V lAE jr(t)-s(t)jdt 

Time-weighted integral of absolute error: 

lAET =^^r(t)-s(t)|tdt 

Integral of squared error: Y 

ISE.=jf[r(t)-s(t)]^dt 

Time-weighted integral of squared error: 

T 

lSET'=jT[r(t)-s(t)]^tdt 


The IE criterion appears at the outset to be too simple to be workable, 
since errors of opposite sign will cancel, giving an unrealistically small mismatch 
value. The squared-error criteria, ISE and ISET, as compared to lAE and lAET, 
assign Increasingly higher weight to large deviations, which seems a reasonable 
thing to do. Even higher powers can be used, such as I4E, I6E. The time -weighted 
criteria, lAET and ISET, give higher weight to persistent errors than transient 
errors, and higher weight to bias errors than to oscillating errors. Further 
properties of various integral criteria are discussed in Ref. 121. 

5. 5. 2. 3 Feature Extraction 

A potential problem in the use of the simple criteria described above Is that the 
Individual attributes of the response — frequency, damping, phase, etc. — cannot 
be Individually identified in the result. It then appears desirable to devise 
algorithms for processing time-history data to extract these individual attributes 
of the response. If desired, a single numerical criterion could then be devised 
by forming a weighted sum of the errors in the individual attributes; the weighting 
could be varied with the simulation context, as previously indicated. 
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Limited experience to date Indicates that feature extraction is' likely Lo be 
difficult for complex systems. Further work in this area should be undertaken. 

5.5.3 Agreement Between Manual and Automated Comparisons 

A simple experiment was conducted to shed some light on how well the results 
of automated comparison might be expected to agree with subjective judgements of 
simulation fidelity. 

t 

5.5. 3.1 Experiment Description 

The simple linear system shown in Figure 5,5-6 was forced with a unit step 
input. With a selected set of parameters and zero initial conditions, the 
"reference" time-history shown in Figure 5.5-7 was obtained. "Simulation" time- 
history data v/as generated by using the same linear system, with random errors in 
parameters and/or initial conditions. Ten simulation cases were generated in 
this manner. For each case, a time-history plot was generated for subjective 
evaluation, while the -fidelity was also evaluated by a number of objective 
criteria. The resulting plots are shown in Figure 5,5-8 . 

Copies of the ten time-history plots v/ere made with uniform scaling, and 
distributed to ten experimental subjects. All subjects were engineers at our 
Houston Operations facility. The subjects were classified by their experience 
in simulation: those in the "high" experience group had from one to fourteen 

years' experience (mean of 6.0 ’years); those in the "low" experience group had from 
zero to one year experience (mean of O.A years). 

Each subject was instructed to rank the ten cases as to how v/ell the 
simulation data matched the reference data; the actual instruction sheet is 
reproducted in Figure 5.5-9 . The subjects v/ev’e not told v;hat criteria to use 
in this evaluation, nor informed as to the context of the simulation from which 
the data were taken. Conversations with subjects following the experiment 
indicated that the weight given to various response attributes — initial response, 
final error, oscillation amplitude and damping, etc. — varied widely among 
subjects; however, several subjects in the high experience group indicated that 
they gave highest weighting to initial response characteristics, perhaps due to 
familiarity with the role of visual /motion cues in simulators. 
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FIGURE 5.5-8 . TIME-HISTORY PLOTS OF "REFERENCE" AND "SIMULATION" DATA USED IN THE EXPERIMENT 
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1, This experiinent will take you only a fev/ minutes, 

2, The attached plots represent ten attempts to match a given 
“reference" data time-history vnth a simulation program. On each 
plot, the reference and simulation time-history data are plotted on 
the same axes. Your task is to evaluate (rank") how well the ten 
simulation trails succeeded in matching the reference data, 

3, Spread out the time-history plots so that you can easily see and 
compare all of them. The plot which, in your judgement, shov/s the 
best match betv/een the tv/o curves should be ranked 1; the next 
best ranked 2; and so forth down to the vforst match, which should 
be ranked 10, 

4, Take your time; look them over. When you are sure of your ranking, 
mark each plot v/ith its assigned ranking in the top right corner; 
circle it. Then staple the entire set together and return to 

P. B, Schoonmaker, E917, Beta, 

5, To maintain standard experimental conditions, please do not discuss 
the experiment v/ith anyone until it is completed. 

6, Thank you for your cooperation. 


FIGURE 5.5-9 . INSTRUCTION SHEET DISTRIBUTED TO SUBJECTS IN EXPERIMENT, 
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5. 5. 3. 2 Subjective Comparison of Time-History Data 

Table 5,5-1 summarizes the subjective ranking data for all ten subjects. 

As would be expected, the greatest unanimity is shown for the best and worst 
matches, with considerable scatter for the intermediate cases. Scatter would 
probably be lower in a real application, where the context of the data was known, 
and hence the relative importance of various response attributes would be better 
understood. 

Table 5,5-2 compares the subjective rankings accorded by subjects in the 
high and low experience groups. The low-experience data' seems to show slightly 
greater scatter, and some significant individual differences in ranking. As an 
objective measure of the comparability between the two groups, we use the "rank 
correlation" given by 

N (W^-1) 

th 

where d. = the difference between the two groups’ mean ranks for the i — case 
N = the number of cases (10) 

For these data, r = 0.962, which is quite high (r is always between plus and 
minus one). Overall, then, the differences between the two groups are not 
important for these data. Differences with respect to individual criteria will 
be evident in the following discussion. 

5. 5. 3. 3 Comparative Ranking for Simple Criteria 

Table 5«5-3 shows the numerical values and resulting ranking for each of 
the simple objective comparison criteria: maximum error, and the five integral 

transformations previously listed. Ihe ten-subject mean subjective ranking (MSR) 
is also shown for convenient comparison. The IE criterion must be converted to 
absolute value (AIE) to make any sense at all; and as expected, it shows some 
wide departures from the results for the other criteria. Note that lAE and ISE 
gave the same objective ranking for these data. 

Table 5,5-4 • summarizes the comparison of subjective and objective ranking 
for the simple mismatch criteria and the mean objective rank (MOR), using the rank 
correlation algorithm previously shown. Correlation values are shown for all 
subjects, and separately for the high and low experience groups. As expected, 
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TABLE 5.5-1 . SUBJECTIVE RANKING OF EXPERIMENT DATA 



RANKING BY INDIVIDUAL SUBJECTS 


'High" Experience 


'Low" Experience 


RANK SPREAD 


High Mean Low 



TABLE 5.5-2 . SUBJECTIVE RANKING FOR DIFFERENT EXPERIENCE GROUPS 







RANK SPREAD 

"High" 

Experience 

"Low" 

Experience 

High 

Mean 

Lov/ 

High 

Mean 

Low 

9 

9.2 

10 

9 

9.6 

10 

2 

2.0 

2 

1 

1.8 

2 

5 

6.4 

8 

5 

6.2 

8 

5 

6.6 

8 

2 

4.6 

8 

6 

7.0 

8 

6 

7.2 

8 

3 

3.2 

4 

3 

3.4 

4 

1 

1.0 

1 

1 

1.4 

3 

4 

4.6 

6 

4 

5.8 

7 

9 

9.8 

10 

9 

9.4 

10 

3 

5.2 

8 

3 

5.6 

8 
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TABLE 5.5-3. OBJECTIVE RANK 3 FOR SIMPLE CRITERIA 


CASE 

MSR 

MISMATCH VALUE/RANK 

RANK SPREAD 

E 

max 

AIE 

lAE 

lAET 

ISE 

ISET 

High 

Mean 

Low 

1 

— 

9.4 

0.879 

9 

0.422 

4 

2.948 

9 

11.203 

9 

1.411 

9 

4.286 

9 

4 

8,17 

9 

2 

1.9 

.153 

2 

.618 

.6 

.618 

2 

1.789 

3 

.065 

2 

.147 

2 

2 

2.83 

6 

3 

6,3 

,753 

8 

n.78i 

9 

1.792 

8 

5.931 

7 

.620 

8 

1.161 

7 

7 

7.83 

9 

4 

5.6 

.510 

6 

.406 

3 

, .883 
5 

1.903 

4 

.233 

5 

.293 

4 

3 

4,50 

6 

5 

7.1 

.472 

5 

1.623 

7 

1.628 

6 

6.282 

8 

,432 

6 

1.328 

8 

5 

6.67 

8 

5 

3.3 

.231 

4 

.206 

1 

.657 

3 

1.782 

2 

.094 

3 

.178 

3 

1 

2.67 

4 

7 

1.2 

.138 

1 

.270 

2 

.287 

1 

.610 

1 

.023 

1 

.029 

1 

1 

1.17 

2 

8 

5.2 

.187 

3 

.579 

5 

.851 

4- 

4.116 

5 

.099 

4 

.478 

5 

3 

4.33 

5 

9 

9.6 

1.089 

10 

3.732 

10 

3.732 

10 

12.289 

10 

2.162 

10 

5.104 

10 

10 

10,00 

10 

10 

5.4 

.730 

7 

1.748 

8 

1.748 

7 

4,622 

6 

.571 

7 

.823 

6 

6 

6.83 

8 
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the AIE criterion shows the poorest results* and should therefore not be used as 
an evaluation method. 

One apparent difference between the high and Tow experience groups is evident 
in their correlations with the time-weighted criteria, lAET and ISET. The low 
experience group apparently gave higher weight to persistent errors, as shown by 
the fact that the correlation with lAET was higher than with lAE, and their 
correlation with ISET v;as higher than with ISE. This carried through to the all- 
subjects correlations^ but results were mixed for the high experience group. 

Overall, the maximum-error criterion seems less useful than any of the 
integral criteria, and the squared-error criteria seem better than the absolute- 
error criteria. On the basis of these limited data, then, v/e would make the 
following recommendations for simple mismatch criteria: 

(a) Use ISE for cases where initial dynamic response is important, 
such as visual, motion, and instrument- readout Inputs. 

(b) Use ISET for' cases where persistent errors are undesirable, particularly 
variables which lie upstream of integrators in the system. 

5.5. 3.4 Comparative Ranking for Feature Extraction 

The features which were considered potentially important in subjective 
evaluation of mismatch were initial position, initial slope, and final value of 
the total response curve, and the frequency, damping, amplitude and phase of the 
oscillatory component. Even for the simple dynamical system used for this 
experiment, the oscillation frequency amplitude and phase proved surprisingly 
difficult to extract. This would seem to indicate that they may be particularly 
difficult to extract for complex dynamical systems. Therefore, the value of the 
first peak v/as used as a rough indicator of the oscillation amplitude, and the 
time of the first peak as a rough indicator of the initial phase of the 
oscillatory component of the response. 

Table 5,5-5 summarizes the correlation of errors in these response features 
or attributes with the subjective ranking of the experiment time-history data. 

All rank correlation values are rather low, indicating that no individual 
attribute is dominant in the subjective evaluation of fidelity, at least for 
these data. 
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TABLE 5,5-4. SUBJECTIVE/OBJECTIVE EVALUATION COMPARABILITY FOR 

SIMPLE MISMATCH CRITERIA 


SUBJECT 

GROUP 


RANK CORRELATION VS. 

CRITERION 


^max 

AIE 

lAE 

lAET 

ISE 

ISET 

MOR 

High experience 

0.919 

0.536 

0.940 

0.931 

0.940 

0.945 

0.931 

All subjects 

'.905 

.558 

.946 

.954 

.946 

.971 

.943 

Low experience 

'.872 

.562 

.933 

.959 

.933 

.979 

.935 


TABLE 5,5-5 . SUBJECTIVE/OBJECTIVE EVALUATION COMPARABILITY 
FOR FEATURE-EXTRACTION DATA 


SUBJECT 

GROUP 

RANK CORRELATION VS. ATTRIBUTE 

Initial 

Value 

Initial 

Slope 

Final 

Value 

Frequency 

Damping 

First 

Peak 

First-peak 

Time 

High experience 

0.451 

0.594 

0.422 

0.749 

0.586 

0.596 

0.400 

All subjects 

.528 

.547 

.524 

.750 

.617 

.644 

.377 

Low experience 

,586 

.482 

.608 

.732 

.630 

.673 

.336 
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For feature extraction to be useful in automatic compdrison and evaluation 
of simulation data, further development will be required in two areas; 

(a) Development of efficients reliable algorithms for extraction of 
individual response attributes from time-history data. 

(b) Formulation of a composite performance index — i.e., a v/eighted 
sum of the errors in various response attributes — which parallels 
the subjective weighting of experienced simulation engineers. 
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SECTION 6 

CONCLUSIONS AND RECOmENDATIONS 

Conclusions and recommendations compiled from all sections of this report 
are listed belov;. The number(s) in parentheses after each item indicate the 
section(s) in which supporting rationale may be found. The conclusions and 
recommendations are listed in the order of the section in v^hich first mentioned; 
no ranking of importance is implied, 

1, Simulation validation should be performed by a staff which is organizationally 
independent of the staff responsible for simulation development (3,0). 

2, Simulation validation must be performed at the isolated module level, at 
Intermediate stages of integration, and in the final all-up man-in-loop 
configuration (3.0, 5.2), 

3, Attention should be concentrated upon the "critical" performance parameters 
of each simulation module in performing simulation validation (4.0, 4,1, 
5.3,2). 

4, Each of the four types of reference data source — closed- form solutions, 
independent math models, existing analysis/simulation programs, and test 
data — has particular advantages and disadvantages for simulation vali- 
dation- (4.2), 

5, Host simulation modules vn'll require both static and dynamic check cases 
for thorough validation (4.2,1, 4,7). 

6, Libraries of existing simulation routines offer many candidate reference 
modules for validation. However, modifications will be necessary in many 
cases (4. 2. 1.3, 4.7), 

7, Driver routines must be developed for module validation exercises: both to 
provide the inputs representing interfacing mqdules, and to ensure format 
compatibility bebjeen the reference and simulation data (4.7, 5.1.2, 5.2). 

8, The integration/validation sequence for a simulation should be based upon the 
natural "clustering" structure of strongly-interacting modules. Efficiency 
vnll be Improved by scheduling module development to be consistent vnth this 
module Integration/validation sequence (4,8). 

9, Early establ ishnient of working interfaces v/ith component and system test 
groups will help to ensure timely access to appropriate reference data under 
desired test conditions (4,9). 
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10, Service routines will be required for printout, plotting, data handling, data 
comparison, and validation data base management. An early start on the de- 
velopment of these service routines is required to ensure that they will be 
available vihen needed (4,10, 4,11, 5,1), 

n. For efficient development of the required service routines, “customized" 

software should be minimized by the early and uniform application of certain 
standards : 

a) Data formats and file structures for reference and simulation data 
files (4.10,2; 5,4). 

b) Data base management system implementation consistent with CODASYL 
standards (4,11). 

c) Module/driver interfacing (using COMGEN or an equivalent support 
software package) (5.1,2). 

12. Hand entry of non-machine-readable reference data into the computer is not 
recommended. Corresponding simulation data should be output in compatible 
formats for manual comparison and evaluation (4.10.2). 

13. A thorough "make or buy" analysis should be performed before undertaking the 
implementation of a data base management system for the validation data base 
(4.11). 

14. For al i-up simulation validation, use of a “canned man" (pre-recorded manual 
inputs) is preferable to man-in-loop operation (5,2, 5.3). 

15. Efficiency and thorough exercise are the basic criteria for check case 
design/selection (5,3). 

16. For initial validation of a simulation, check cases should be sequenced on 
the basis of steady expansion of the operational envelope; the opposite 
approach is recommended for revalidation following modifications (5.3.2, 
5.3.3). 

17. The acceptable fidelity for a simulation varies with time, as the system 
being simulated becomes better defined, and more accurate reference data 
becomes available (5.5). 

18. Automated comparison techniques which correlate well with the subjective 
judgement of experienced simulation engineers are presently available, 
Hov/ever, further development of "feature extraction" techniques is 
recommended (5.5.3). 
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